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

In my post ? Or in Rick’s ? It’s only there in my original post…not in Rick’s…

I digged a bit more and you can find a paper on 32 vs 64 bit on the RPi3 here

The Dhrystone-Results are similar to the other link. Some other show no speed gains. Of course if NEON is used that would end up the same anyway…but in the end…the topic here is quite simple…if we can’t run RISC OS on the latest future RPi’s or whatever device somebody has to do the port to 64 if we want to run it on the latest hardware…there’s no such a thing as a “choice” anymore.

A certain set of records is needed that the application knows is in chunk 38 of the 1GB memory chunks it is devided into, so it makes a call requesting what it sees as Chunk 38, the OS then looks at the page table information, and the application mapping information,

I’m inclined to think if you’re doing that, “you’re holding it wrong”.

The user application has no business knowing where and how its memory is allocated. All it needs to know is that it has from here to there for itself, with the ability to expand/contract as reasonably necessary.
A good example here is RISC OS where every application thinks that it starts at &8000. Clearly this is not true. This is just what the application believes. How and where the OS actually gets that memory from, and what happens to it when the application isn’t “active”, is not the application’s concern.

(for more elaboration between logical and physical memory on an older MEMC setup, I delved into the MEMC CAM table back in October → https://heyrick.eu/blog/index.php?diary=20201004 )

If, however, you mean an application that really does have a massive amount of data (Gigabytes) split up into its own system of chunks… I wonder if that isn’t something that is also best handed over to the OS as well. For example we all know that applications that deal with video, especially editors in the HD+ realm, will deal with large amounts of data. But, then, is it really necessary to load an entire set of video files into memory in order to edit them? Sure, it’s faster, but you’ll find memory filling up in a hell of a hurry. Seems to me like with fast media and good caching, it ought to be possible to run with a smaller dataset in memory and load a lot of the video data “sort of as needed”.

I can think of other things, but they’re more specialised than something an average user might want to deal with.

I digged a bit more and you can find a paper on 32 vs 64 bit on the RPi3 here

Thanks. That is… ridiculously detailled. ;-)

It seems, generally, that 64 bit is “slightly” faster. How much depends on what is actually being done, and there are some things 32 bit seems to do better though I wonder if compiler maturity would help this.

Yes I realise you are attempting to argue that 64 bit is the only round

Uh, actually the number of bits didn’t factor into my thinking at all. Sure, with bigger addressing you can logically address more memory; however my thinking here is that complicated large memory handling is possibly best left to a competent (as in not RISC OS) operating system to handle as best suits the hardware. Load it all, fake it from disc, use sparse allocation, whatever. Let the OS worry about the implementation.

We (RISC OS users) are kind of at a disadvantage here. We allocate, we get a chunk of contiguous memory. The rest is pretty much up to us. Sliding heaps? Garbage collection? Yeah, about that… :-)

The CPU being tested on is designed to run native with the AARCH64 ISA, so uses a compatibility mode to run ARM code.

The ARM has two execution states. A 32 bit one and a 64 bit one. There’s no compatibility mode, they’re both native.

Slides from ARM: http://www.armtechforum.com.cn/2014/sz/A-6_64-bitAndroidOpenSource.pdf
Page 3, quote: Full native 32-bit execution, side-by-side with 64-bit

so compiled tests can never be a completely reliable benchmark.

True. I would expect 64 bit to perform better as compiler technology matures.

And they are using the kinds of benchmarking that are known to be quite unrealistic to daily usage.

Most benchmarks are synthetic, as daily usage is small bursts of speed (load this web page now dammit) followed by a lot of doing very little. We notice when the browser takes a second too long to load something. We notice when there’s a pause as virtual memory kicks in. We don’t notice the five minutes it takes to read the article, or the two and a half hours lost on a wiki walk. But we all want the compiler/assembler to run really smoking hot fast when we want it to.
I’m not sure there’s really a viable benchmark that matches human behaviour. So we make do with artificial things, using the logic that if one system runs the exact same set of tests as another system, then one can make comparisons between them as to which is “faster”. I put it in quotes because some machines perform extremely well at certain things while sucking at others, granting plenty of leeway to massage the results.

Nice real-world example for 32 bit vs. 64-bit: Run RPCEmu on Ubuntu Server 32-bit (40 MHz) vs. Ubuntu Server 64-bit (50 MHz). I guess the difference is the allocation of variables to registers by the compiler. As everyone will have found who tries to translate a (BASIC) procedure into assembler, pressing 30-50 variables into 16 registers is a real challenge. Having ~ 32 registers is much easier, especially for a compiler. I guess, the need for having more registers and wider memory adressability, above 4G, (with its need to differentiate between 32- and 64-bit transfers), ie. finding unused bits in the instructionword, is the real reason why the condition-code bits had to be given up. And once those were given up, more could change. A bit like the Great Vowel Shift, but then in processor instructions.

when taking a break from real computing

I would wager that in the real world, asides from financial/educational institutions, most processor cycles consumed are the result of either web browsing or cat videos.

Someone else may be encoding MP3s in there computer down time,

My phone can do a ten minute symphonic metal song in about thirty five seconds…

you perform a search

Google used to be good, back in 2010 or so. Then it get heavily polluted by stuff like expert sex change (I’ve split the words differently). Now? Now there’s an annoying habit for it to not find a phrase that’s in a page that you’re looking at. It’s as if “user isn’t looking for Dua Lipa, Trump, or Apple so we’ll just tell them there’s nothing”.
Problem is, most people think Google is where they find stuff, so if it’s not on Google (or needs some crazy magic incantation in order to find it), it might as well not exist.

or transcoding video formats, etc etc.

When I used to do that on my PC (DVD rips, mostly), I’d set up Handbrake, give it the default priority level, then just leave it running in the background.
Usefully Handbrake has the option to hibernate the machine when done, so I have sometimes run it at a higher priority and just left it on in the night, knowing it’ll power itself down when finished.

In other words the results could be purely the C compiler and nothing to do with the archetecture.

Possible, yes. But I would assume the 64 bit would be the one to benefit. Anything compiling on 32 bit ARM has had over twenty years to get to grips with the instruction set, and at least a good decade to understand things like dual issue optimisations.

so not a lot of confidence in performance tuning of the HW for 32bit.

ARM may be moving beyond 32 bit, but it’s not as if they said “oh sod it, let’s just shove an ARM11 core in here and be done with it”, so what you said is rather demeaning to the people that design these processors.
The fact, as is being pointing out, is that on the exact same hardware a switch to 64 bit does generally have measurable benefits in raw execution.

They are focused on AARCH64 instead.

Yes, they’re thinking of the future. Might behove us to do likewise.

This may be simplistic, but something I have thought about a lot, is the time when 64-bit ARM becomes the only ARM available. I have thought a LOT about how RISC OS could fit into this new era.

The RPi 3 and 4 have 32/64 CPUs. If someone could invent some ‘magic’ which could enter the CPU in 64 bit mode, then run RISC OS in 32-bit mode, sort of like an ultra-slim hypervisor, then we could run RISC OS natively, and have the ability to ‘CALL’ 64-bit code. A simple model would be RISC OS runs on the first core, and the next core is used for 64-bit mode in the desktop, and the next is used for 64-bit mode outside of the desktop.

Using a system where a modified Dynamic Area could be created within RISC OS, and a programmer can compile or load AArch64 code into that, and data, and ‘CALL’ it, would allow us to explore AArch64. It isn’t as much fun as ARM32, but it has some attractive qualities (30 registers 64-bits wide!).

If we could add this most basic 64-bit support to RISC OS, it could allow us to extend things. With a LOT more work, it would be possible to mix 32 and 64 bit modules (especially if we keep all modules in the lower 4GB initially). And we could use the 8GB in the Pi 4.

Such a system could allow RISC OS to survive, and allow a gradual transition to AArch64. When 32-bit cores vanish, emulation is still extremely fast -
RISC OS could survive for ages as an emulated 32-bit OS living in a 64-bit world, with applications being 64-bit, and only the OS being 32-bit.

Utopia would be running RISC OS 5 (32-bit) in a 64-bit world, and using the resources already developed, to find a way to maintain compatibility with 33-bit RISC OS on a pure 64-bit platform – and then adding 26-bit support, which by definition is ARM710, but even SA110 emulation can be done easily. It would kind of be like the ultimate Apple Rosetta, allowing RISC OS to migrate to 64 bit, and supporting, again, RISC OS 2, 3.10, 3.11. 3.x etc, at a speed higher than on old-school hardware.

This could all start with running RISC OS 5 on a Pi 3 or 4 in 64-bit mode. I’ve been doing a lot of proof of concept work the last 2 years. Would this be of any interest to anyone?

@tymaja: Sounds interesting !

@Jan:

As everyone will have found who tries to translate a (BASIC) procedure into assembler, pressing 30-50 variables into 16 registers is a real challenge. Having ~ 32 registers is much easier, especially for a compiler.

I think that’s exactly where I would find a benefit while coding my little intros/demos…you always run out of registers. Even more recently when I used Thumb/Thumb-2 code where you would only want to use r0-r7 to keep the code small, but that’s another story. Though recent speed ups in memory access and intelligent caching kind of minimize the memory access overhead.

I remember back in time when you and me where optimizing that radix sorting code on RISC OS. That could be more of a real world scenario were 64 Bit would instantly make sense, as you could sort 64 Bit numbers/indexes instead of 32 Bit…would be kind worth to try some day at least on a linux environment on the RPi4.

This could all start with running RISC OS 5 on a Pi 3 or 4 in 64-bit mode. I’ve been doing a lot of proof of concept work the last 2 years. Would this be of any interest to anyone?

Anything you’ve got there would be of interest to everyone in the RO world.
It’s two years work probably no one else has done.

True. I would expect 64 bit to perform better as compiler technology matures.

Or JavaScript JIT compilation engines for example.

The RPi 3 and 4 have 32/64 CPUs. If someone could invent some ‘magic’ which could enter the CPU in 64 bit mode, then run RISC OS in 32-bit mode, sort of like an ultra-slim hypervisor, then we could run RISC OS natively.

That would help with processors that can’t boot in 32bit mode, while being compatible with 32bit code. And that’s what RISC OS on Linux can do. On the other hand, do not forget that new ARMv8 technologies do not implement 32bit support at all. But, yes, that will give us more time.

When 32-bit cores vanish, emulation is still extremely fast

Yes, but 64bit processors will need to become much faster than today to beat a native RISC OS working on a 2 GHz Pi4 :)

This could all start with running RISC OS 5 on a Pi 3 or 4 in 64-bit mode. I’ve been doing a lot of proof of concept work the last 2 years. Would this be of any interest to anyone?

Yes. I think RISC OS on Linux is a good base. Work to be done:
1/ Finish it :)
2/ Slim down Linux to make a Pi hypervisor
3/ Define tools for ROS / Linux interaction
4/ Define a gateway for native 64bit code use from the RISC OS environment

those that have no interest in computing at all. Those are the ones I call the touchers

I call this the “mechanic syndrome”. There are those who understand cars. They tune their engines. They mod. They are concerned with fuel/air ratios and brake horse power.
And there are the overwhelming majority who don’t really care about how it works, only that it does so they can go to work, go shopping, go about their lives.

It’s the same with computers. Loads of people have insanely powerful hand held devices that they refer to as a “phone” and they use to look up stuff, listen to streaming radio, watch TV, take loads of photos they’ll never look at again…

The thing is, neither user is wrong.
Consider, for example, how much design and development goes into gaming. The ultimate end user is likely not a programmer and doesn’t care about the deep technical stuff, only relevant issues like latency and frame rate. They want their games to be the best they can be, they don’t care how, only that it is.
Moms on a school run want a car that’s reasonably safe, fuel efficient, and easy to handle. They don’t care how, only that it is.

Point?

It can encode a fairly long MP3 in less time than it takes to set the thing up to do it in the first place, so it’s probably not really a “background task” any more.
Yes, I remember when encoding to MP3 needed to be cached as a wave file because the machine couldn’t do it realtime. That was a long time ago. Even my lowly XP-era PC can rip from CD at around 6x while carrying on multitasking…

it is not going to do quite as well running ARM ISA, now is it.

I don’t think the performance is necessarily going to be worse as there are two separate execution states. It seems to me that the primary casualty was the removal of SWP but that may have less to do with the processor and more to do with the memory management and how it wouldn’t necessarily be an atomic operation.
Still, it had been deprecated for a while so its removal shouldn’t have been a surprise.

This could all start with running RISC OS 5 on a Pi 3 or 4 in 64-bit mode. I’ve been doing a lot of proof of concept work the last 2 years. Would this be of any interest to anyone?

Very much so!

I notice that DavidS has got a fair amount of “flak” for his view, drawing comparisons with Flat Earthers and the like.

I must admit that before I had read more of his postings, where he described in more detail his ideas and the reasons behind them, his support for the 32-bit ISA made me wonder if he was some kind of Luddite, stuck in the past.

However, having read his later postings, I realise he’s neither a Flat Earther nor a Luddite, quite the contrary. For me, he’s a visionary, and as such, you tend to attract a fair amount of criticism from those who support “status quo” (AArch64).

I’m reminded of this quote:

“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new.”

- Niccolò Machiavelli

I’m all for experimentation, especially when the best way ahead is not clear at all.

Yet, we also know what choice ARM Ltd has made, so it may not be wise to put all our eggs in one basket, something David readily admits.

Thus, I think there is space for going in both directions, meaning exploring a potential new 32-bit ARM ISA processor, while at the same time looking into how we may move our beloved OS to run on 64-bit platforms.

Thus, I very much welcome @tymaja’s initiative, of somehow booting a 64-bit ARM in 64-bit mode, running RISC OS in a 32-bit mode segment/core, and then starting to look into how we might write 64-bit running on RISC OS.

That’s the motivation for having recently acquired a Raspberry PI 4, myself: To be able to start playing with 64-bit ARM code.

As I’ve mentioned elsewhere, I also intend to look into the possibility of making a version of the extASM assembler for 64-bit code, meaning we’d be able to assemble 64-bit ARM code under RISC OS.

It’s ultimately a coffee vs tea situation, in that neither side is “right” and neither side is “wrong”.

RISC OS 5.x will still be here if some people depart to pastures 64-bit, and likewise, a project to create RISC OS 7 (or whatever a 64 bit version might be called) doesn’t need everyone to be on board.

as I am getting tired of arguing the same thing

The simple answer is… don’t argue.
There are those who wish to consider a potential port of RISC OS to 64 bit processors. And, obviously, those who would prefer to say with the platform as it is now.

Ultimately, one is not going to replace the other because it’s unlikely that with the exception of simple BASIC programs, any 64 bit incarnation is not going to be in any way binary compatible and may well have a notably different API.

ARM as in the 32bit ISA

Call it ARM32 or something, because AArch64 is ARM too, only different.

is likely to still be in new products for at least the next ten years before the switch to application level AARCH64 is complete.

Citation needed. And please don’t say, again, that one can still buy ARM7500 or whatever it was. Those are likely left-over chips in inventory. Not something actually being produced. Not something actually being used.

Meanwhile, in the world, mid and higher end Android phones and most (all?) current Apple phones have already made the transition. I can imagine it slowly trickling down to the lower end hardware. As ARM have put an actual end date on 32 bit, this transition will only accelerate.
Even on the Pi family, for the last two major versions there has been a choice of 32 or 64 bit.

We have zero reason from my view to run from our ISA to something different. We should be spending this effort on modernizing RISC OS as an ARM OS.

The thing is, we’d need to toss out most of the existing codebase in order to make a transition to 64 bit, so this offers the potential of an exciting journey in which RISC OS can be redesigned with regard to modern practices and not what was “the way” in 1982, plus recreating it in a higher level language (probably C as we’re not exactly blessed with lots of compilers), plus a potential wider range of available hardware. If the new RISC OS is not as firmly tied to the processor architecture as it is right now, it ought to be possible to backport it to 32 bit ARM, or maybe even to x86? Okay, that last one is a bit left field, but if it is possible then one could say we’re doing the remake correctly.

Again, there are people still happily using functional RiscPCs; so if we all run off and install RISC OS in place of Windows (well, I can dream…) this doesn’t mean that RISC OS 5.28 running on your Pi2, Pi3, Pi4 (etc) will suddenly cease to exist. They’ll still be there, and there may be a number of people who choose to stick with the old simply because learning a whole new system and API is just not something they can be bothered to do. Some will, some won’t. It’s natural.

Trying to make it an AARCH64 OS is a waste of resources that could be better spent improving it as a ARM based Operating System.

I will agree that a rewrite for 64 bit ARM is a pretty long shot, given that RISC OS has survived for far too long with what is pretty much volunteer effort – I’m not demeaning this, I’m just pointing out that the smallish amount of work “around other (paid) work” is the reality, so quite how an AArch64 bit version would actually happen is… um… yeah… oh look, a unicorn!

RISC OS does indeed need improvement. A lot of improvement. But this doesn’t mean that we should simply forget about any “going forward” in terms of ARM evolution. Looking at stuff that has been done along the way, it looks like rather a lot of it is “scratching a personal itch”. Look at the project to get RISC OS running on Linux. Look at Gerph’s pyro server. None of this had to happen. But they did because somebody thought “hmm, wouldn’t it be nifty if…”.

RISC OS needs a lot of modernisation. But this shouldn’t preclude the possibility of evolution.

getting my CPU documents retyped and up on my site.

You know anybody with an all-in-one printer? A quicker solution might be to simply scan the documents and make them available as PDF or JPEG images?
Alternatively, there may be people around these parts who could do some OCR on them of they’re printed and not handwritten?

Coming back to people attempting to flee the ISA has been exhausting at the least.

and:

then the one that every one trashes, as a waste of time by everyone that has coded for it in the last 20 years, will still have a use to someone.

You say things like that and then wonder why people get upset with you.

Nobody is “fleeing” anything. If, and it is a BIG if, RISC OS starts to make realisable plans for a 64 bit version, the existing 32 bit will still be around.
It will still be open source.
It will, likely, still be built at regular intervals for those using machines that are not 64 bit compatible.
And, as such, I can imagine people will still provide code and bugfixes and such for it. It may receive less “official” support because “exciting new project” and all, but it isn’t suddenly going to vanish.

Likewise, to suggest that everybody who has coded for the current RISC OS for the last 20 years has been a waste of time is, frankly, offensive.
32 bit RISC OS is right here, right now. All of the work leading up to this point is available to run on the machines we’re using today.
Is that somehow insufficient? Inadequate?

I am even working on an outline to add a desktop environment more Atari like in nature once the other Atari stuff gets far enough,

You accuse those of us who think an AArch64 version as a good thing of “fleeing”, pointing out numerous things about the differences between 32/64 that are basically complete fabrications, and yet at the same time you want to turn it into some sort of Atari clone?

And as for the Atari desktop… you mean something like this?

Or: http://xaaes.gokmase.com/images/screenshots/mathias1.jpg (1679×1049)

Wow – in terms of visual appearance, it looks even more dated than RISC OS! I don’t know what to say, so I’ll just stop here and go cook some farfalle…

Perhaps we need a new forum category for ‘Beyond Aldershot’. Alton.

As you change the meaning yet again.

Oh, FFS. Your interpretation of English must be remarkably different to mine if you don’t think statements like this are simply rude:

But since you seem to prefer to dismiss most of what I say with something about twisted meanings and then follow on with reposting the same thing I was responding to for a third time……welcome to my killfile.

PS:

Hence why I am not even attempting to respond to those that change the meaning of words to sound negitive anymore.

Except you did, for several screenfuls.

Perhaps we need a new forum category for ‘Beyond Aldershot’. Alton

Bognor¹ has a royal precedent for dismissal.

¹ Technically Aldwick.

May I suggest to all the use of Chris Gransden’s latest improved version for RISC OS of James Bursa’s “Sargasso”, an RSS feed with programmable exclusions!

Just want to dig up this topic to make an observation…

I have just received my new freebie Android tablet (take a year’s subscription at less than the cover price, and they’ll send you a free tablet… I fail to see how this is actually profitable for them).

Anyway, it’s one of these no name Chinese thingies with an RK3326 processor. That’s a quad core (up to 1512MHz) Cortex-A35 device with a Mali-G31 GPU. Not a bad screen on it, but sadly WiFi performance is lamentable and the “speaker” is comically poor. At least it has a headphone jack.

Of more importance, it’s an ARMv8 device. 64 bit capable, bit it is running Android 9 Go in 32 bit mode.

So if tablets that are given away are moving to 64 bit hardware, I think we really have to understand that 32 bit has had its day.

…

BTW, WTF has Mozilla done to Firefox? Just installed the latest version. It’s… awful. And looking at the available add-ons, there is a choice of eleven things. ELEVEN. That’s beyond mediocre.
This new Firefox? Best damn thing I can do is take it out back, stick a bullet in its head, and copy across the 60.0.2 apk file from my phone. Because this 84.1.4 build is just not exciting. It’s nice that I can add UBlock origin… But cookie autodelete? Tracking cookie obfuscator? RSS previewer? Smart referrer? Google search link unmunger? These are all essentials.
Did I mention the list of available add-ons lists eleven things? I think people are voting with their keyboards over messing with the extension system. I think I shall to, by downgrading to a version that does what I want it to do.

Ah, v60 to v84 culture shock. Scrapped the old NAPI

Open a PDF in the browser – no add on or 3rd party external required
Google search link fix is what I think you should look for
Various cookie managers as add ons, but “Delete cookies and site data when Firefox is closed” in the options sounds like what you’re asking for.
Tracking cookies – have a look in the Security options

And back to add ons / extensions, query in the search box – after you’ve checked what they’ve now built in.

v60 to v84 culture shock

Indeed it is. “One that works” → “WTF is this?”.
They scrapped more than the NAPI, if the official add-ons page is to be believed.

Open a PDF in the browser

Would rather download the file so I can read it in whatever.

but “Delete cookies and site data when Firefox is closed” in the options sounds like what you’re asking for.

No, it really isn’t. I don’t close Firefox on Android. It sort of gets pushed as a background app when I’m doing something else, and may or may not get unloaded by the OS (my S9 is quite aggressive here, my tablet less so).
It’s worse on the PC. I use Hibernate, so I don’t think I’ve closed Firefox in weeks.

No, what I’m looking for is something that will destroy cookies when a tab is unloaded, and otherwise every 120 seconds unless the given site is whitelisted. In other words, cookies are only active for as long as they need to be.

Plus something to fix Google’s search links to be non-tracking ones, and discard Referer text from Google (massive privacy leak, they send the entire search request). One I recall from a short while ago was somebody in Wales (going by IP) was sent to my ancient screenshots of a certain Buffyverse witch with the search phrase “Willow’s gorgeous titties”. The first word is correct, the rest, not so much. :-)
Plus something to detect RSS and display it in a nicely formatted style rather than raw xml (like Firefox used to do).

This evening, I downgraded to a working version of Firefox, installed all of my preferred add-ons (using Google because the Firefox site tried its best to be obstructive), now it’s all working nicely. ;-)

The processor is only clocking around 300MHz more, but this tablet is much more responsive than the older one. Nicer display too, you don’t have to look at it at exactly the right angle.

Anyway, I “fixed” Firefox, the sledgehammer method. :-)

> So if tablets that are given away are moving to 64 bit hardware
> I think we really have to understand that 32 bit has had its day

The 64-bit A35 is mass-produced, and therefore much cheaper than the 32-bit A32, which is only used for embedded applications.

So we will soon end up with only high-priced 32-bit remaining, and most of these will have no GPU, or just RGB interface and no HDMI