Thinking ahead: Supporting multicore CPUs

You do understand correctly. Whether the ARM processor can do anything useful while waiting for the VFP to produce results depends on what percentage of the work being done is in the VFP, and whether the programmer has considered how to organise things to take advantage of the possibilities (if writing in assembler, or how good the compiler is otherwise).

I suppose a really cunning programmer might do part of the work in VFP, and part of it using integer instructions in the core…but we’re back to balancing programmer time against execution time again. And the optimum might vary from implementation to implementation anyway.

All my thunks on this subject should be taken with a bucketload of salt, since I’ve not done anything with it since documenting it all in 2007…

That’s an even bigger difference than I expected.

I’ve not done empirical tests, but using ABC, my raycaster in VFP massively outperforms the same thing as FPA. I’d imagine it would equally outperform anything Norcroft could create.

That is a big time advantage.

Exactly. The FP unit can run semi asynchronous to the processor, but when it’s emulated…

I suppose a really cunning programmer might do part of the work in VFP, and part of it using integer instructions in the core…

Only to find that it works great on this one core, but this other one that does speculative out of order execution gives worse results and… ;)

If you’re writing cunning code in assembler in 202x, then you’re either supporting something so obsolete and retro that it commands silly prices on eBay, or you’re simply doing it wrong.

For signal processing applications, which include simple graphics transforms like shearing, a binary fixed-point representation is usually enough. For us, this means that a 32 bit multiply-accumulate is enough for many use cases.

If you’re writing cunning code in assembler in 202x, then you’re either supporting something so obsolete and retro that it commands silly prices on eBay, or you’re simply doing it wrong.

Exactly. Sorry if I made the point too ironically! I tried to make that obvious when I wrote “And the optimum might vary from implementation to implementation anyway.” Which of course is exactly the same point as your “Only to find that it works great on this one core, but this other one that does speculative out of order execution gives worse results and…”

But if your algorithm doesn’t need floating point, it’s unlikely that VFP will really compete against integer arithmetic in the core.

Out of Order Execution should never make anything worse!

The entire point is to take code which may have been generated for a generic ARM core, or a optimised for a different specific core, and re-schedule it in the most optimum way for the core it is actually running on. This will also include optimum scheduling for the various FP units.

Out of Order Execution should never make anything worse!

Of course not – but it can make one option better, that’s worse on the core you optimised for. It can’t change an integer operation to a FP one or vice-versa.

So you’re discussing how to make 26/32-bit RISC OS which AFAIK is pretty stuck to a single-core, single-thread Arm CPU running in cooperative mode.

This is where the logistics of rewriting 26/32-bit R.O. to support preemptive multitasking, write an RM or such which is loaded very early in the boot sequence to allocate cores/threads to programs which start up and after the desktop is reached. Versus rewrite R.O. in C, compile it to 64-bit to make it compatible with the most modern Arm CPU/GPU’s, make a new SDK with 64-bit compiler plus write a transparent RISC OS 3.7 emulator running in the background to support legacy software.

Breaking this project up into teams, one can do the core (4 programmers), one the RMs (4 prog.), 4 to do the SDK and 2 to do the emulator, 14 programmers in all. I’d be happy to be corrected regarding how many per team +/- but don’t bark at me for continuing my “RISC OS 64” campaign, grounded in an earnest wish for RISC OS to survive beyond a dwindling enthusiast/32-bit fanatic crowd. It deserves better.

<insert exasperated comment of your choice here>

Are we not sliding into the realms of off-topic and derailing this technical thread? I feel a sense of deja vu here → https://www.riscosopen.org/forum/forums/5/topics/13283#posts-87368

SWT is a troll. We should all stop feeding it.

Elsewhere, it was said:

and I’m pretty sure you’ll bounce once again on another topic.

Oh look. Colour us all surprised.

14 programmers in all. I’d be happy to be corrected regarding how many per team

You think it’s doable? Fine. Sources are available. There’s nothing in the licence that would stop you setting up a little company with X programmers to get on with the work.

Just don’t expect us to band together and do it for you. There are plenty of other things that need done that are more viable. Let’s say, onboard WiFi, those other three cores, etc etc.

but don’t bark at me for continuing my “RISC OS 64” campaign

We aren’t barking at your earnest desire to have a 64 bit RISC OS. We’re annoyed that you are regurgitating the same bollocks over and over.

Which part of “there’s no money to pay for the 14 programmers” do you fail to understand? This isn’t us being reticent or obstructive, it’s a plain bloody reality. Money makes the world go around and right now us little people have less and less. Squeezing your eyes shut and wishing really hard might help you win a farting contest, but it won’t make any new OS appear.

It deserves better.

It deserved better in 1987. It certainly deserved better in 1990 when we were otherwise running apps on DOS on the god-awful x86.
But, like with ßetamax, “better” and “popular” are two very different things.
So, yeah, it deserved better and it deserved more love from its parent.

On the other hand, the sources are legitimately available. Can’t say that about all the older OSs…

Feel free to go ahead and roll your own 64 bit version of the OS.

rewrite R.O. in C

No, you don’t just rewrite it in C or whatever. If you were going to do anything, you’d reengineer the entire system from the bottom up. As it stands, the core OS is absolutely not up to being considered a modern OS. It’s already been explained why. A lot.
Suffice to say, a rewrite fit for purpose would not much resemble the OS as it is today.

compatible with the most modern Arm CPU/GPU’s

What’s so special about ARM, eh?

Take a look around you at the world we’ve come to know
Does it seem to be much more than a crazy circus show?
Maybe from the madness, something beautiful will grow
In a brave new world, with just a handful of men,
We’ll start… we’ll start all over again!

Oh, and… 🎤💧

Squeezing your eyes shut and wishing really hard might help you win a farting contest, but it won’t make any new OS appear.

Oh man! Now it’s my tea, that is spread all over the place!

So Mr. Swales, why not give me yours? The fact that Arm V.9 doesn’t support anything 32-bit anymore doesn’t concern you at all? Give a hint that going 64-bit may be a very good idea?

Because, unlike you, I am actually using it. To support other RISC OS users. e.g. adding ability to use hardware floating point to Fireworkz (and for any other person who cares about such things).

Not, it does not concern me one bit, let alone 64.

Somehow this reminds me of a hospital series from the USA :-/

[Edit]
Which got deleted.

Let’s not feed the troll.

Grnf.. all I ask is if the work required to make 32-bit work with all its 26/32-bit programs on multiple cores/threads versus doing you know what. Without utilizing features in modern Arm instruction sets which could project a 3D RISC OS Desktop for instance with realtime raytracing. That’d be cool. Go a bit New Millennium. Support modern standards (USB, WiFi) and generally being the best GUI around. Grown-up RISC OS.

Peter pan style, I don’t believe in…

Let’s not feed the !

How can anything you say be taken seriously since you’re still http://www.gkc.org.uk/gkc/books/secret-people.html ? Riddle me that. No French Kings, please. Nor cringing “jews”.

https://www.helsenorge.no/en/psykisk-helse/mental-healthcare-for-adults-in-norway/

Mr. Ruck, I nearly choked on the cereal, but the flat screen is a simple wipe down job.

Please remember Christmas is a terrible time of year for suicide:-(

The fact is that the number of RISC OS users have taken a nosedive since Acorn Ltd’s demise, and the market has done the same with companies like Computer Concepts leaving ship long ago. Are people blind to the fact that this is a trend with no sign or reason for reversing it? It can hobble along as long as there are people willing to fund the production of 32-bit-compatible ARM CPUs with no regard for their best GPUs supporting real-time raytracing and other useful functions. In short, it’s a game of diminishing returns with a R.I.P. ending.

Unless.

Look, we all know this. It’s a toy OS at this point, 32-bit, ridiculously insecure, but fun. Telling us this doesn’t help anything, and speaking personally, it just feels a bit like you’ll probably try to take credit for convincing people to improve it, if they do.

Let’s all not feed the troll.