Will RISC OS survive in a 64-bit-only ARM world?

Hi all.

I’m a bit at crossroads, now. I’ve been working for a while reimplementing the sprite functionality using C/C++, and I’ve become somewhat discouraged when it turned out that I needed substantial amounts of ARM assembly code to be on par with the OS, performance-wise, which has kind of negated some of the aim of the project, which was to reimplement things in higher-level languages, so I’ve been wondering if it’s even worth it…

On the other hand, with ARM’s recent announcement of the 64-bit ISA, then it appears that it’s not a question of if, but when we’ll get processors that only run 64-bit ARM code. Yes, I know the first processors will be able to run 32-bit code, too, but the first ARM-processors had support for 26-bit addressing, too, for a while…

We may well end up in the medium to longer term, maybe 5-10 years, possibly further off, where the new ARM processors will only run 64-bit code.

What then?

I’m wondering if we have enough people, and enough people who care enough, to make the transition to 64-bit for RISC OS, if or when that will be needed.

Or will we just say, “Well, that was fun,” and leave RISC OS behind…?

Or “worse”, continue running on increasingly outdated hardware (been there, done that; don’t want to go back there).

If the community thinks that it just won’t be worth it to transition to 64-bit for RISC OS, then I’m wondering if my time might be better spent tending to flowers in the garden, or something, rather than working on RISC OS… :)

Because then, in a relatively short time, we’ll be out of (new) hardware again, for good…

Your thoughts, please.

If much of RISC OS by then is reimplemented in C/C++, the transition should be much smoother, as it wouldn’t mean rewriting everything, just recompiling the OS, and rewriting the lower-level processor-specific code.

The same goes for transitioning the applications, of course.

I’ve become somewhat discouraged when it turned out that I needed substantial amounts of ARM assembly code to be on par with the OS, performance-wise, which has kind of negated some of the aim of the project, which was to reimplement things in higher-level languages, so I’ve been wondering if it’s even worth it…

Of course it’s worth it. I think the problem is that you chose something that C/C++ compilers aren’t very good at – producing optimised code for bulk reads/writes to uncached memory.

We may well end up in the medium to longer term, maybe 5-10 years, possibly further off, where the new ARM processors will only run 64-bit code.

What then?

I’m wondering if we have enough people, and enough people who care enough, to make the transition to 64-bit for RISC OS, if or when that will be needed.

5-10 years is a long time. Plenty of time to rewrite the OS in C, and plenty of time for more developers to arrive.

Or “worse”, continue running on increasingly outdated hardware (been there, done that; don’t want to go back there).

Don’t forget that we’ve still got lots of catching up to do before we’re able to take full advantage of the hardware we’ve got available today. So even if we weren’t able to use new 64bit-only processors for a while, we’d still be able to get performance gains by improving support for 32bit hardware (multi-core support, non-blocking file I/O, graphics acceleration, etc.)

Thanks, Jeffrey. That certainly makes me more encouraged, and as you say, there’s a lot we may do to improve RISC OS giving it higher performance on _today_’s hardware.

Terje, what you’ve done so far is extremely valuable, so don’t be discouraged. Even if there is the odd key routine that still has to be hand-crafted in assembler, a huge amount could be happily replaced by C/C++. I think it’s definitely a move in the right direction (much as I enjoy assembler!) Keep up the good work ;)

Did you write the code so that when compiled it can either use the hand crafted assembler or just the C/C++ equivalents?

If so, then wouldn’t that reduce any problems caused by a major change of processor?

By the time a 64 bit ARM is the only option, hopefully compilers would be cleverer and and processors will obviously be more powerful, so if no-one rewrote the assembler part, it wouldn’t be a disaster.

Hi W.P.

Thanks for the encouragement, as well. Yes, I agree with you: When a system like Linux can be written mostly in C, and be considered one of the fastest operating systems there are, then surely doing the same for RISC OS should be possible, as well.

Moreover, when we went from no platforms at all (except the Iyonix/A5Home, but no successor appeared there) to several platforms that RISC OS runs at, just from a few volunteers (and a lot of work), then this shouldn’t be beyond us, either… :)

Jess:

Did you write the code so that when compiled it can either use the hand crafted assembler or just the C/C++ equivalents?

There were origininally code there for doing it purely in C/C++, yes. However, the problem was that – for this particular function, plotting a row of a sprite – the difference in performance between the C++ version and the assembly version was several orders of magnitude, so that it is unlikely that in the short run, a compiler will be able to compile roughly as performant code.

However, there’s no big deal at all to reintroduce the C++ code, should that happen.

More likely, the C++ code that was replaced by assembly code should be written in a more low-level fashion, to match more closely the way it’s done in assembly code, and in that case, with a good compiler, it might approach the assembly code version in performance.

From a code maintenance point of view, that code wouldn’t be that much more maintainable than the corresponding assembly code, though, as the intent would be lost in low-level operations, but it’s certainly a possibility if needed, like if moving to a 64-bit ARM ISA.

If so, then wouldn’t that reduce any problems caused by a major change of processor?

Yes, already today, it’s manageable to switch, by rewriting that code in low-level C/C++.

With today’s compilers, I suspect that the OS would be 2-3 times faster than this low-level C version, though, so we might as well use the assembly code version of that routine for now, and instead replace it if either compilers become good enough when targetting ARM, and/or we need to, due to a change to 64-bit ISA.

just recompiing the OS

From looking at stuff that’s “just C” and moving it between processors at work I know that it’s rarely a simple recompile. I’m sure everyone has assumed sizeof(void *) is 4 somewhere and used an int (assuming that is 4 too) to hold the pointer.

If you’re itching to do some C++ and fiddling with sprites, but don’t want to craft any assembler, how about adopting !ChangeFSI ? It’s an offline renderer so can affort more cycles per pixel, has lots of input formats that need transforms of various sorts applying to it: adding a new file format class would be a lot easier that figuring out how to do it presently!

just recompiing the OS

From looking at stuff that’s “just C” and moving it between processors at work I know that it’s rarely a simple recompile. I’m sure everyone has assumed sizeof(void *) is 4 somewhere and used an int (assuming that is 4 too) to hold the pointer.

Yeah, I’m fully aware that was an “oversimplification”. Yet, compared to rewriting the assembly code for a completely new ISA, it’s “just”… :)

What I was getting at, was that was that you should (if possible) include both the original c code and the assember, with a choice at compilation time to use either. (Obviously for the forseeable future always using the assembler.)

This would mean that anyone trying to use it on a new processor, would be able to get it running with the minimum of fuss, and could leave getting it running quickly until later.

What I was getting at, was that was that you should (if possible) include both the original c code and the assember, with a choice at compilation time to use either. (Obviously for the forseeable future always using the assembler.)

Yes, I understood that, and I’d be happy to do that, but what I meant that it would likely need to be rewritten to use a different algorithm, closer to how the assembly code does it, or the world’s best compiler would probably still be one or more orders of magnitude slower.

This would mean that anyone trying to use it on a new processor, would be able to get it running with the minimum of fuss, and could leave getting it running quickly until later.

Yes, I understand, but I still think that it would be better to “port” it properly to a new ISA, by at least rewriting the C++ code that was replaced into a routine using a different algorithm.

Just to give you an idea of what kind of changes this would make: The existing C++ code that was replaced used the concept of “pixel iterators”, which – in a straight-forward implementation – means that it performs 32 reads/writes from each word, to plot 32 pixels in a 1 BPP mode…

In contrast, the way the OS does it, and the way the assembly code in the new module does it, is to read a bunch of words, shift the bits in them to the right, to align them with the screen alignment, and write them back as a bunch of words. One LDM/STM will do six words in a single instruction, while the C++ version will do an LDR/STR for each bit (and having to read from the screen for each one, also).

Having had to depart from the “pixel iterator” method, I opted to go straight to assembly code, rather than writing the same low-level code in C++, but that would be an option, too, if someone would like to do that, or if it’s needed for a new ISA.

So the bottom line is, I think rewriting the assembly code, rather than keeping the “pixel iterator” approach, is a more fruitful way.