When will the Iris web browser be released to mere mortals

Chris Hughes post came while I was writing mine. Yes, I also read the ReadMe, and am trying to ‘get my head round’ the technicalities. I don’t pretend to understand technicalities of Webkit; but, if the explanation given by Chris Hughes (ROD?) is correct, then won’t Webkit browsers run on other ARM platforms with other OSes (e.g. Apple’s Safari?) also corrupt data?

I made some tests: JavaScript is on par with the Raspberry Pi OS browsers (1 core of course) and Chrome on Core i3.

The Javascript JIT in Iris looks to be running quite slow. At least according to the Kraken Javascript benchmark.

Browser              OS      Total Time      CPU Speed
Qupzilla     RISC OS 5.29    14987.0ms       Rpi400 2.4GHz
Iris         RISC OS 5.29    29533.0ms       Rpi400 2.4Ghz
Chrome 90      MacOS 11.3      614.1ms       M1 3.2Ghz
Chromium 88        Rpi OS     4082.2ms       Rpi400 2.4Ghz

The risk of data corruption from running programs with Alignment Exceptions off is down to the fact that ARM changed the behaviour of unaligned loads/stores.

• Old RISC OS software (i.e. from old compilers, or old hand-written assembler) will be assuming the old behaviour. Run one of those old programs on a new CPU which implements the new behaviour, and things can easily go wrong.
• New compilers (when told to target new CPUs) will want to produce code that uses the new unaligned load/store behaviour. Run one of those programs on a new CPU and it’ll work fine without any risk of data corruption.

There’s also the opposite problem (new program on old CPU could fail because of the differences in unaligned load/store behaviour), but for that scenario the program is likely to have safety checks to ensure it’s running on a compatible CPU.

Other OS’s generally solve these compatibility issues by being a bit more aggressive with cutting off support for old builds of programs (and having much better infrastructure to help ensure programs are regularly rebuilt with the latest compilers/libraries).

@Jeffrey
Thanks for the answer, but it leads to an obvious question.

New compilers (when told to target new CPUs) will want to produce code that uses the new unaligned load/store behaviour. Run one of those programs on a new CPU and it’ll work fine without any risk of data corruption.

So, do you know how our versions of Webkit and Iris were compiled, on a newer compiler for ARMV7 (or later) or on an old compiler compatible with ARMV6 or earlier?

They’ll be using the new unaligned load/store behaviour. The only reason to use the old behaviour would be if they were specifically targeting the Iyonix, RiscPC or Archimedes – good luck getting something as resource-hungry as WebKit running acceptably on those.

Good. So why are we asked in the Iris readme to turn Alignment exceptions off?

So why are we asked in the Iris readme to turn Alignment exceptions off?

Because the JIT part uses Thumb instructions, which are 16-bit, i.e. half-word, and somewhere in that library are some unaligned loads.

I guess it might get fixed in due course, not least because Linux should have the same issues – alignment exceptions are a function of the CPU, not the operating system. (Unless the Linux compiler fixes the unaligned loads…)

If alignment exceptions are on, the CPU will trigger an abort/exception whenever software tries to perform an unaligned load/store.

Iris wants to use unaligned loads/stores, so in order to allow it to run, alignment exceptions must be turned off.

Wouldn’t it be better for users to give reports on the errors?

How about Iris tries an explicit unaligned load (wrapped in exception handler) in main() and issues a dire warning if it does raise the exception?

@Alan
While away from the forum (eating my dindins) the possibility that the problems were in the JIT part occurred to me, since it was just when this was introduced into Iris that the Alignment Exceptions off advice was given, not before. Silly me, for not realising before I posted!

What I find interesting is that Linux with its vast numbers of programmers has the same issues.

To clarify, there are (up to) three ways in which a CPU can be configured:

• Use the old unaligned load/store behaviour
• Use the new unaligned load/store behaviour
• Disallow unaligned loads/stores

If you’ve got some code which wants to access unaligned data, compiling the program to use the new behaviour will result in the best performance. Compiling it to not use unaligned loads/stores at all will result in the worst performance. Compiling it to use the old behaviour will be somewhere in the middle (actually, probably the same performance as if it didn’t use unaligned loads/stores at all, since the old behaviour was only useful in a small number of situations).

So new-style unaligned loads/stores are A Very Good Thing for performance.

The Linux distributions like Linux to be fast, so for distributions which target ARMv6+ they’ll almost certainly be running with the CPU configured to use the new behaviour.

From WebKit’s perspective, the only ARM devices they care about are capable of using the new unaligned load/store behaviour, and the only OS’s they care about are running with the new behaviour enabled. So they’ve written the JIT to produce code which uses the new behaviour.

Also note that ARMv6 is the only CPU architecture which allows a choice between the old & new behaviour; newer CPUs only support the new behaviour (or turning alignment exceptions on to disallow unaligned loads/stores), while older CPUs only support the old behaviour (and might not have a way of turning alignment exceptions on).

IIRC there was a plan that after RISC OS 5.24 was released, we were going to change the ROM build settings so that the (ARMv6+) ROMs are built to use the new unaligned load/store behaviour. I’m not sure what happened to that – maybe it just got forgotten.

Thanks for that explanation.

So new-style unaligned loads/stores are A Very Good Thing for performance.

IIRC there was a plan that after RISC OS 5.24 was released, we were going to change the ROM build settings so that the (ARMv6+) ROMs are built to use the new unaligned load/store behaviour. I’m not sure what happened to that – maybe it just got forgotten.

Taking those two comments it sounds like we’re currently complaining about real world application performance (browsers etc) and then shooting ourselves in the foot by not enabling the faster version.

The Javascript JIT in Iris looks to be running quite slow. At least according to the Kraken Javascript benchmark.

With the Kraken JS Benchmark, I suspect Iris runs into problems with memory allocation, network transfers, CMT, etc. Smaller benchs, as SunSpider, give very good results here.

I got Iris now. My experience so far:
- Google Drive works fine.
- Even webapp-games as ‘entanglements’(sadly no sound yet) is working fast enough..
Loading speed of iris (RasPi400-RO-Direct) is comparable with ‘firefox portable’ on windows10(intel i7-8core 3GHz)

That means we have finally a comparable browser on Risc Os!
(Sure missing to set prefered language for websites and such… but Iris is not yet in final version)

Therefore a big thank you to the developpers. Well done!