No more big 32-bit cores for RISC OS from 2022

Had they went with the other kind of paralell execution, then keeping conditionals would have made the dependancy mapping a lot simpler than having to use only conditional branches, and thus would have been easier to keep all execution units busy at all times.

i.e. ULIW and predicates (conditionals on steroids), interesting yes, but in practice no – look how well that worked for Itanium. First version was a decade late, subsequent iterations were desperately underwhelming, while conventional ISAs (such as ARM64) ran rings around it. ARM definitely made the right choice with AArch64.

@DavidS

Thanks a lot for your substantial reply, much appreciated.

I’m not a microprocessor expert, and you’ve inspired me to look more closely into these issues. Also, I’ll carefully read your reply and follow up any references.

I really, really like the elegance of the original ARM processor, and I understand from your reply that the approach taken with AArch64 was not the only one possible.

Working with extASM has been a delight when using ARM assembly, since you may write such compact and elegant instructions.

Take this simple example, implementing the C sgn() function:

CMP R0,#0
MOVLT R0,#-1 // extASM will transform this to MVNLT R0,#0
MOVGT R0,#1

This executes in 3S cycles no matter what. The alternative with only conditional branches is much more convoluted and unpredictable performance-wise.

This also works nicely together with optionally setting the PSR, so you may have code like this:

// Some computations, setting the PSR to the result
// Some more computations, executed unconditionally, not setting the PSR
// Some conditionally executed instructions, based on the earlier result

I’ll address the license issues of extASM. I don’t remember the exact terms now, but it’s certainly free for anyone to use and distribute, and I’d welcome its inclusion in various distributions, such as making it freely available on the RISC OS Open site.

Thank you for bringing back the newer version of ExtASM, I had lost my copy and with the host that had it dissapearing I thought I was stuck without it. I will be making sure to keep a copy on my site so the future does not keep it from being found again.

Thank you. :)

I’ve been away from the RISC OS community for a long time, but using other systems like Windows has its way of reminding me just how great RISC OS is.

Furthermore, the recent Cloverleaf campaign gave me hope for continued evolution of RISC OS, although having realised later that the posted roadmap was more based on hope rather than being backed by a plan with resources behind it.

Coming back to RISC OS Open, I’m delighted to find a community that’s alive and kicking, and I realise of course that what brought us where we are today is development done by earlier RISC OS copyright holders (such as Castle), as well as developers in the RISC OS Open community.

Coming back to ARM: Even though AArch64 may not be what we’d like it to be, for better or worse, it’s the 64-bit ARM processor, and as such is the one that is and will have wide usage in mobile computing and beyond, with implications for RISC OS.

With this in mind, i.e. this thread, I intend to explore the possibility of making a 64-bit version of extASM, i.e. still running on 32-bit RISC OS but taking 64-bit ARM assembly as input and producing 64-bit machine code.

This would enable us to start playing with 64-bit code in RISC OS already today, such as on the Raspberry Pi 4, which I’ve recently ordered for just this purpose.

in the hopes of finding the correct group of people.

Might I suggest you get in touch with the British “European Research Group”? They believe in unicorns and fairy dust and seem to have a way of making bad ideas sound vaguely positive by completely ignoring all the potential negatives.

@DavidS

Now had ARM chosen to use a fan in parallel pipeline implementation to improve instructions per clock, then they would be shooting themselves in the foot with there choice here, as they made the dependancies between instructions less helpful (relying on branches for conditionals does not work out very well if the per instruction dependancies are used to improve instruction per clock execution).

You can look up the many university papers on it.

I did a search for “microprocessor parallel pipeline implementation”, but didn’t really find that much, and what I found tended to be academic papers behind a paywall.

If you could provide links to online resources or books, I’d appreciate it.

Also once I get some things on this posted on my site, with appropriate references to information, then you can look there.

I’d love that.

Now they use methods that require the use of speculative executation to more extent, and thus wastes resources executing instructions that have to be rolled back later in more cases than ever should.

Very interesting. I’d love to learn more about this.

>Shift and operate in the same instruction, which can lead to some rather compact and elegant code

This one I do not understand being dropped. I can not see where it is an advantage to drop, though I can see the advantages in keeping it.

Then we are on the same page. :)

>No multi-register load/store. I really like the ability to load/store the entire register set with a single instruction. That’s no more.

This one I do understand the reasoning for. And there are arguments both ways on it, as it is possible to implement in a true RISC fashion today, with wide cache fetch busses, and good decode trees. Though there is the complexity of circuit argument that is equally valid (though they more than made worse than what saved by going OOE).

I’d love more elaboration on this part. While I understand that LDM/STM may increase the upper-bound IRQ latency, it seems you’re talking about something else here.

For me, it doesn’t make a lot of sense to have to pore on instructions to save and restore registers, if a single one would do, but I’d be happy to be educated on this point.

>The PC is no longer treated as a normal register.

Unfortunately, loosing out on some possible enhancements.

It was fun, wasn’t it? :) And it made implementing jump tables very easy.

Had they chosen the much wider possibility (as far as instructions per clock per core) of using parallel fan-in pipelining, without any use of speculative execution and minimal OOE, then the use of conditionals per instruction would have helped do more instructions per cycle do to clear dependancies.

That would have been great, and it should significantly reduce the need for a lot of branch prediction and rollback of wasted execution, as you pointed out earlier.

I believe, largely as the result of it having already been proved on test HW in the mid 1990’s at many a university, that they could have exceeded 4 instructions per clock per core averages for much real world software had they went the other way than they did.

Someone should give them a stern talking to. :)

Though ARM has made its bed with what I truely believe is the less capable means of SuperScalar execution. So they will sleep in it for the AARCH64. There loss in potential.

Groan. And with an architecture that is mostly “ARM” in name, only, as you’ve pointed out.

There’s never been a shortage of RISC processors, but ARM used to be special.

IT is my main OS

This is my dream. It’s not yet, but I’m moving there. Paul Vigay once wrote: “Windows is a stress inducer, RISC OS is a stress reducer.”

This is how I feel as well. Continuing to use Windows is just not good for my heart, as I keep thinking “This would be so much easier in RISC OS!”.

Yes, I know there’s Linux, and while it may be an improvement over Windows in some sense, it’s missing more or less everything I appreciate in RISC OS.

For references, I have a huge list that will eventually end up on my site along with detailed documentation on how to implement these methods of superscalar design in real future CPUs using the ARMv2/3/4/5/6/7 ISA to acheave very good results.

If your site is already up and running, even without these things, could you post a link?

If not, please post one once you have put some of these things up.

Sorry about the length of the above response. You caught me while I am sifting through documents on RISC Pipelines, Parallel execution implementations, Fan-in pipelines, OOE and RISC, Specular Execution, Implementations of pipelines with multiple cross points to improve performance in fan in pipeline implementations, and releated topics.

I’d say that was lucky timing. :)

From another posting:

Using standard 32 (even tested with one ISA that was 16bit) bit RISC ISA implementation, ARM being one of the test ISAs. IT is a method of using a fan in pipeline with a given number of execution units, the fan in before execution being based on dependancies (including those caused by the condition for ARM and every instruction conditional), thus making the most effecient setups those with every instruction conditional, and minimal use of normal branching.

Talk about turning the AArch64 philosophy on conditional execution on its head.

For me, it never really made sense that having lots of little branches in the code – and consequently more instructions as well whose only job was to jump to a different place – was supposed to be more efficient than intelligently using conditional execution – coupled with other things like optionally setting the PSR and shift-and-operate in the same instruction – which tend to lead to dense, and I must say, code that is a delight to work with.

However, I don’t yet have the knowledge necessary to compare these different approaches.

I don’t know if I’d ever want to write 64-bit ARM assembly code, beyond potentially working on a translation or emulation layer for 32-bit ARM instructions on 64-bit ARM hardware.

From yet another posting:

There being another way forward will only be of help if we can get the correct people interested in putting some support into it. As such I am working on attempting to put togather a huge amount of documentation so that I can see about getting some of the correct people interested in what I see as the better approach.

I, for one, sure am interested in such an alternative approach.

Whether I’m one of the “correct people” is another matter. :)

@DavidS Thanks a lot for your replies, and I’m very much appreciating all the work you’re putting into this.

Make sure you get time off as well, and enjoy the holidays. :)

Still attempting to figure out what group of people are most likely to be of aid in pusing forward the ARM in the Classic ARM ISA form.

You just need to find people who are happy to pay much more for much less performance, and are also happy to wait a few years – or perhaps decades – before such a solution may be available.

Should be easy.

when there are fewer 32bit ARM systems available

Do you expect all Pi4 to vanish after the Pi5 will be out? :)
I can still easily find Pi 1 on eBay in France.
Not bad for 8+ years old product.

can not afford a used RISC PC

Blimey. I had 12 RISC PCs at one time, bought for a song when my former employer stopped using them. Gave a couple away, used a couple for years, gave some to a museum. The last two, that I used for years, both with Strong ARMs, went to the dump once I’d got the Pi up and running. Little did I think they’d ever be worth anything…

Still attempting to figure out what group of people are most likely to be of aid in pusing forward the ARM in the Classic ARM ISA form.

Is the idea to design a 64-bit ISA that retains the 32-bit ISA architecture, with 64-bit registers, and perhaps more registers, or is the idea to create a faster 32-bit processor through superscalar processing?

If the former, and if we’re going to retain the 32-bit instruction size (which I think is a good idea) and increase the number of general-purpose registers to 32 (as in AArch64), I guess we’ll need additional three bits that we need to get from somewhere.

I definitely love the idea, and if there is an architecture – as you’ve indicated – where the greater code density and less branching from conditional instructions is an advantage, rather than a hindrance, then that’s great.

It is still fairly rare to need to perform calculations on integers larger than 32bits in size.

Except in cryptography, where 64bits is still far too small…

The original ARM architecture was actually pretty good at extremely large integers. I wrote routines to handle arbitrarily large integers quite efficiently. One day I might update them to more recent versions of the architecture…only I doubt if I’ll bother…

That is actually a bit of myth.

No, it’s absolutely true of some kinds of encryption, and as you say, irrelevant in others.

If your encryption involves (as extremely strong encryption does) modulo arithmetic modulo the products of very large prime numbers, then you can be handling very large integers.

The work you’ve been doing is evidently in one particular branch of the subject; I’m retired, but one of my former hats was as a lecturer in Mathematics, and this is one of my areas of expertise. I got my job at ARM partly on the strength of my knowledge of ARM assembly language, mostly gained working in precisely this area.

No need for 64bit, not until an application needs more than 256TB ram (the potential quick bankable on request limit of the ARM MMU), or can not handle banking through chunks that fit inside of the 3.whatever GB that we would max out at for direct addressing.

It is still fairly rare to need to perform calculations on integers larger than 32bits in size. And the time paging takes is already the same issue with lazy paging, so no significant addition to the delay of access.

Interesting idea, and I agree with you: For the most part, I’d think the top 32 bits of 64-bit registers would be wasted, and takes twice as much space to store.

Do you know anybody else, i.e. outside your research institution thinking along the same lines?

It seems to me that “the world” has more or less adopted by default that we “need” 64 bits, thinking of the increased address range, primarily, not considering how things like swappable banks could work.

We might use the silicon saved this way for other purposes, such as more excution units and parallelism.

If your encryption involves (as extremely strong encryption does) modulo arithmetic modulo the products of very large prime numbers, then you can be handling very large integers.

Or, products of lots of distinct medium-size primes, thanks to the Chinese Remainder Theorem.

Why not, but :
- Don’t expect to beat 64bit processor with a 32bit offer.
- Don’t expect to beat the Pi4 processor with a FPGA soon.

Anyway, the first problem with the ARM 32bit ISA is “how far can I go without breaking the law”. The ARMv2 ISA is really too old, but some suggest that the ARMv4 ISA would be in public domain now (or soon). That will need to be checked if you want to have a good and stable base for a new and more modern Amber core.

An open source ARM classic core (eventually with an optional 26bit support) would be great for many and could have a lot of uses (especially in the embedded market).

Or, products of lots of distinct medium-size primes, thanks to the Chinese Remainder Theorem.

Indeed, and there are more examples in number theory where handling extremely large integers is fun, if not necessarily actually useful (yet…)

That said, having registers much longer than 64 bits seems pretty silly, when it’s not hard to write software to handle extremely large integers in 32-bit registers & RAM, never mind 64-bit or more. Where the optimum place to draw the line is, I have no idea. But I’m inclined to the feeling that if one has any long registers at all, there’s absolutely no reason why all the registers need to be very long. As others have said, there are better things to do with the extra silicon…

Not sure it should be a consideration in CPU design though, as not very practical.

I’m very sure it shouldn’t be, although I’d add a very speculative “yet.”

We can operate on arbitrary size integers through 32bit registers and a bit of memory

Exactly.

A desire to address more than 4GB of memory is the main driver to >32bits, I’m pretty sure, having been privy to discussions among the engineers at ARM up to late 2007 – and then an unwillingness to contemplate a register size that wasn’t a power of two.

Given that the instruction size remains 32 bits, I’ve never quite worked out why they couldn’t have most of the registers 32-bit, and maybe the first four or eight registers longer – possibly even implementation defined, starting at 40-bit or 48-bit and increasing by a byte or two as and when anyone feels the need.

But that’s all water under the bridge now – unless someone feels like branching the architecture… gahh!

Of course you can page memory, ad infinitum should you be so inclined, no reason to stop at 256TB; that’s been done since CPUs had 8-bit registers. But it makes for more complicated memory systems.

I can easily understand the desire to go beyond 32-bit registers, and I remember engineers at ARM discussing this 13 years ago and more. I don’t think they were being driven by marketing at that point. It’s the size of the step up that’s the big question – and I remember similar discussions about whether the step up from 8-bit to 32-bit was too big a step when most other companies had gone to 16-bit, or whether it made any sort of sense to go to 24-bit.

The first computer I really got to grips with had 12-bit words…that was 1968.

Right, can we get back to discussing RISC OS moving to 64 bit processors, rather than bring back 32 bit or ever 26 bit processors, and other flat earth nonsense.

take that one in a billion case and shove it down your throat to make it be seen as the magic of everyones needs for every thing

I believe the issue is two related but different things.

Firstly, in order to be able to manipulate pages of memory (they’re swapped around all the time, either in and out of “nowhere” like RISC OS does on Wimp polls; or to/from disc on systems with virtual memory), something needs to be able to see the entirety of the addressing space.
There are workarounds for having all the memory shuffling work on 8GiB systems with a processor that can ‘see’ 4GiB, however these are not as optimal as being able to address it directly.

Of course, it’s a better situation than the problems of having 128MiB fitted into a RiscPC with a processor stuck in a mode that can only directly address 64MiB (that’s why the limitations on application size, RMA size, etc on those machines).

Yes and no. In some ways having more than a couple gig in a flat address space makes the choice of structure and order a bit more complex.

There’s a difference between “flat address space” (ie. no MMU) and “being able to see everything”.

The second issue is in the continuing evolution of the instruction set. While the original ARM set was aimed at programmers and had a beautiful flexibility practically unmatched elsewhere, the number of people writing code in assembler is negligible these days. It’s all compilers and such, which have decades of maturity in their code generation. It’s no longer seen as necessary to have such flexible things as LDM/STM, or have most of the instructions being conditionally executable. Removing these things in the 64 bit world can reduce the complication within the processor. Less complicated means fewer transistors. This can be translated into faster/cooler cores and enhanced optimisations with the pipelining and prediction.

Don’t get me wrong here, I like the original instruction set. But it’s a different world now.

Just out of interest, has anybody benchmarked running a 32 bit Linux on a Pi3/Pi4, and then running a 64 bit build on the exact same setup?

@Rick: As usual of course it would depend what benchmark is valuable to you…but here are quite some indications it’s worth to go 64 Bit => Link

can we get back to discussing RISC OS moving to 64 bit processors,

It’s the same discussion as before. Do we…

1. Start a ground up rewrite of something that will by definition not be RISC OS as we know RISC OS (think of how different the SYS command would be) and this time try to get it right. It’ll ‘feel’ a lot like RISC OS, but internally it’ll be more modern.
2. Start a quick’n’dirty port of the current RISC OS to run on 64 bit systems, basically running a lot like it does right now (and all the legacy baggage) and shhhh nobody mention that &FFFFFFFF + 1 probably won’t do what one might expect it to do.
3. Make some sort of emulator (please, not another RiscPC era machine!) upon which to run what we have right now on fancy new hardware.

While you’re wondering which option is the best and which is the most realistic, remember that we still, at this point in time, only utilise one of four cores (on multicore devices), we don’t have IPv6, nor onboard WiFi, nor anything that resembles a Bluetooth stack, nor a disc format that understands partitions, nor a way of loading arbitrary user code that doesn’t involve handing it the keys to the kingdom and saying “play nice”, nor anything that resembles acceleration for graphics/video operations…
Yes, I’m aware that some of these things are being worked on, but given that things that are just accepted as normal elsewhere are a work in progress for us, who exactly is going to plan and/or write and/or finance this endeavour?

That last bit, that’s probably the real question right there.

but here are quite some indications it’s worth to go 64 Bit => Link

Cheers – that’s exactly what I was looking for. ;-)

Just out of interest, has anybody benchmarked running a 32 bit Linux on a Pi3/Pi4, and then running a 64 bit build on the exact same setup?

Running what though? I’ve benchmarked every variant of Pi in 32 bit, and those that can do 64 bit, with some a couple of programs which are in g++, clang++, C#, pypy, pypy3, Python2, Python3 and Perl. It all comes down to what you are doing; tight CPU bound arithmetic comes out a lot quicker sometimes 50% to 100% faster on 64 bit. Larger code which puts more pressure on the cache can be 20% slower. That holds across all the languages, except for pypy and pypy3 which don’t yet have a ARM 64 bit JIT, so are 20x-30x slower.

What difference would it make for a 64 bit vs a 32 bit RISC OS? Well a pure C 32 bit RISC OS will probably be a bit slower than the hand crafted 32 bit assembler version, and compiled as 64 bit probably slower again on the same processor. But the difference is faster 64 bit ARMs are coming along all the time, and we’ve already seen the faster ever 32 bit ARM.

remember that we still, at this point in time, only utilise one of four cores (on multicore devices), we don’t have IPv6, nor onboard WiFi, nor anything that resembles a Bluetooth stack, nor a disc format that understands partitions, nor a way of loading arbitrary user code that doesn’t involve handing it the keys to the kingdom and saying “play nice”, nor anything that resembles acceleration for graphics/video operations…

It’s the same as the argument for not embarking on a space program until you’ve solved all poverty.

@DavidS: Click on the word “Link” !???