ARMs are not what they used to be

Many years ago, when I had an Archimedes, I bought a copy of Peter Cockerell’s ARM Assembly Language Programming . A glance at some of the current ARM documentation convinces me that there is for RISC OS users today nothing like that book available to bring them up to speed about the CPUs on which present and future versions of RISC OS may run. In the days of the Archimedes the ARM was a relatively simple device, compared with ARMs of today. Since then there have evolved all sorts of aspects on which Peter Cockerell’s book can tell you nothing: multiple cores, caches, interrupt strategies, NEON and VFP, and doubtless much else. I guess the problem is that the tiny minority of RISC OS users who have an inkling of such matters are far too busy applying their knowledge and have little leisure to address the thankless task of disseminating it. Yet these matters are going to be of crucial importance in planning the future of RISC OS. First of all, different versions of ARM chips have different endowments; at some point RISC OS will need some kind of baseline to determine which varieties it can be ported to. Second, many of these new facilities are configurable at switch-on, after the boot code has determined what sort of CPU it is running on, and RISC OS will probably need some protocols to avoid the expense of different configuration code for each ARM chip to which it may be ported. I would expect, for example, that a modern browser project, such as Richard Brown mentioned at the London Show, would need to exploit as many cores as it can if it is to run at an acceptable speed on a Raspberry Pi. The RISC OS kernel is going to have to be extended to cope with all these new facilities that current platforms offer. Backwards compatibility should not be a major consideration – nostalgia can become a stultifying habit.

So this is a hint to certain editors and certain experts. Please educate us.

First of all, different versions of ARM chips have different endowments; at some point RISC OS will need some kind of baseline to determine which varieties it can be ported to.

… the chosen hardware supports the ARM instruction set, contains an MMU, and is capable of using the 32bit processor modes that were introduced with ARMv3. Thumb-only processors (e.g. ARMv7-M), or processors/hardware lacking an MMU, are not supported by RISC OS. ARMv8 processors must support AArch32 at both EL0 and EL1.

No doubt there are some other edge-case things, but apart from the addition of the last sentence, those requirements haven’t changed in the 8 years since I created that page.

RISC OS will probably need some protocols to avoid the expense of different configuration code for each ARM chip to which it may be ported

Quite a few devices use some variant of ARM’s GIC for the interrupt controller. At the moment each HAL contains its own GIC driver implementation; it would be nice if that could be moved out into a separate library or something. Possibly the UART code could be moved out as well (for devices that use standard UARTs).

However the next logical step for the evolution of the HAL might be to start supporting the Linux device tree blob, so that we can have a hardware-agnostic HAL/ROM which configures itself at runtime based on the contents of the device tree supplied by the bootloader.

A glance at some of the current ARM documentation convinces me that there is for RISC OS users today nothing like that book available

ARM is no longer a RISC chip in the literal sense, there must be well over 100 instructions now. Added to that, every core is different, with differing instruction sets and in some cases instruction behaviour. It’s now incredibly difficult to hand code and support many platforms in the same code path.

The ever increasing instruction count on ARM is likely down to the move away from hand coding, to compiling and that’s the direction RISCOS will need to take if its to go “world wide”. Along the way, a lot of CPU support will need to be dropped, in particular ARM6, ARM7, StrongARM, XScale and a few cores used in the early Pi’s as there’s too many variations on MMU, instruction set, CPUOp’s etc.

At some point, it may need to be forked and fixed for legacy machines so all the legacy code can be dropped, which is going to be a brave move!

In the days of the Archimedes the ARM was a relatively simple device,

We are very far from those days. Personally I feel the rot set in with instructions like CLZ, but the problem inherent in microprocessor design that is going to affect RISC devices is that the processor runs much MUCH faster than memory. Back when an 8MHz processor talked to memory running at about the same speed (and ROMs a little slower – remember the RMFaster command?) it wasn’t a big problem to have a small set of simple commands.
Now that processors can run 4-5+ times as fast as memory, even with cache and prediction technologies, it is more and more seen as a worthwhile thing to get more processing done with fewer instructions. This makes the instructions a lot more complex and capable (some of the NEON stuff is mindblowing).

To be honest, I think that advocates of RISC and CISC are both wrong these days. We need a processor that is neither, but provides the advantages required regardless of philosophy. That’s the way it is going.

Since then there have evolved all sorts of aspects on which Peter Cockerell’s book can tell you nothing

These days, the instruction set is designed for compilers, not people. The primary OS on all ARM devices is some derivation of Linux, and remarkably little of that is written in assembler. Most of it is in C. So, yeah, there’s not a lot people have to worry about. Assembler programmers are a rare breed these days. Somebody at work who programs Arduino stuff called me “hardcore” when they found out that I use assembler. My God, even microcontrollers are programmed in a high level language these days. Doesn’t one of those ESP WiFi gizmos support Lua?

at some point RISC OS will need some kind of baseline to determine which varieties it can be ported to

Jeffrey has indicated the ‘baseline’. It hasn’t changed, literally, since the Iyonix brought RISC OS into the proper 32 bit realm.

Second, many of these new facilities are configurable at switch-on, after the boot code has determined what sort of CPU it is running on, and RISC OS will probably need some protocols to avoid the expense of different configuration code for each ARM chip to which it may be ported.

Why? I’d rather it the other way around. Look at the x86 world. You can get a CD/DVD of whatever OS you like (Windows, Ubuntu, Debian…) and shove it into the slot. Power up, boot from CD (if it doesn’t find it automatically) and it just works. Yes, there are loads of drivers in there for specific machines, but the end user doesn’t need to worry about such complications. The OS probes for what is there and loads all the right stuff. In my playing around with Ubuntu, my problem was how rubbish a lot of the software was. Getting the OS running was a breeze, it just started itself up. A far cry from my original foray into Slackware in the mid ’90s when it would look at my video driver (an S3 back then) and panic.

In this respect, ARM was an utter catastrophe. Newer ARM devices support a “device tree” to indicate what hardware is actually present. I suspect a particularly sweary rant by Linus with a threat to drop ARM support (not that it would make sense) might have pointed out the insanity. But even with the device tree, it’s as if every device has a different method of booting. What this eventually leaves us with is multiple ROM images because of the differences in each machine. There’s also no compatibility mode. x86 starts up thinking it is an 8088, and most video devices can fake a VGA display. The BIOS puts keyboard and such in known locations. A PC can get itself going. For RISC OS, the Pi has no clue what to do with the MLO file used by the OMAP; and quite often the OMAP doesn’t either because the bootloader is spectacularly braindead… :-/ Then the hardware differs and a fair chunk of it is often buried under NDAs making implementations difficult – you’ll note that many of the ARM boards with Linux/Android support offer a closed source binary blob to glue the OS to the hardware – and since there is no commercial requirement for any sort of compatible fallback, it isn’t like the x86 world where you can treat an unknown XYZZY Inc QHD graphics adaptor as SVGA or somesuch.

would need to exploit as many cores as it can if it is to run at an acceptable speed […] The RISC OS kernel is going to have to be extended to cope with all these new facilities that current platforms offer.

Ideally, this would be an OS provided service of some kind so that work can be spread around to make best use of the hardware, but able to fall back to slower single core behaviour on single core machines without it being the responsibility of the application to deal with this, moreso as it would allow multiple multi-core style applications to coexist arbitrating as necessary without requiring them to be aware of each other.

Backwards compatibility should not be a major consideration

But it should not be ignored. One of the strengths of RISC OS has been that the breaking changes have usually been caused by external changes to the architecture (26→32 bit, unaligned loads, lack of SWP, etc etc). I’m expecially pleased that we have exactly one SharedCLibrary, instead of the DLL hell seen on other systems.

Along the way, a lot of CPU support will need to be dropped, in particular ARM6, ARM7, StrongARM, XScale and a few cores used in the early Pi’s as there’s too many variations on MMU, instruction set, CPUOp’s etc.

Why? Shouldn’t it be possible to set up a set of routines applicable to the machine at boot time? I think we may need some changes to module initialisation to allow for the loading of applicable modules for the device in question. But, this is a far off thing. Right now I’d settle for supporting the hardware that exists today. ;-)

At some point, it may need to be forked and fixed for legacy machines so all the legacy code can be dropped, which is going to be a brave move!

:-) We probably have different ideas of what constitutes “legacy code”. I understand that you’d want to drop support for RiscPC class, and maybe Iyonix (no VFP).
I’d want to ditch OS_Byte and vdu:. It bugs me greatly that reading the keyboard is a bunch of partially broken¹ OS_Byte calls, and using the VDU driver in text mode is a bunch of partially broken spit-data-to-the-vdu-stream² interactions.

However, as everybody everywhere points out, the question is not whether or not these things can be done, or are good to be done, but simply a question of developer time…

¹ Page Up or Shift Up? It’s reprehensible that Acorn copied this behaviour from the BBC Micro (a machine with no Page Up) to the Archimedes (a machine with).

² VDU 31,x,y takes only byte wide values, so will fail if >255 columns.

I renounce all loyalty to ARM. I pledge full allegiance and full loyalty to RISC-V.

RISC-5 seems like a good idea, but looking at the Wiki description, it’s starting to look a little complicated with numerous extensions and options. Give it a decade, it’ll be where ARM is now. ;-)