Thinking ahead: Supporting multicore CPUs

I’m back.. slobber.. gulp.. a 64-bit RISC OS would in all respects except for the Desktop be an entirely new beast all together since more than three decades has passed since 26/32-bit RISC OS were left in the dust from the ARM (Acorn RISC Machine) since it had evolved way beyond it.

Just think on running RO w. legacy emulation on a https://www.fujitsu.com/global/products/computing/servers/supercomputer/a64fx/#anc-02 , never mind native software, and Bob’s yer uncle. Take the desktop where it needs to be.

Merry Christmas.

And also from the world of AI nonsense. It is possible that an advanced alien civilization could develop a complete 64-bit ARM emulation of a RISC OS Archimedes system if they had the necessary knowledge and resources but we do not know what their technological capabilities are.

Take the desktop where it needs to be.

MODE 12!

MODE 12

That’s old hat. Or to quote BingBot’s inebriated CoPilot “I’m not sure what you mean by “MODE 12””.

Get the NEC MultiSync out and go MODE 20 my friend. Who could want more? Apart from MODE 16 that is?

Does either of these modes make color correction (toward a CMYK gamut for instance )an issue? Can’t check these days.

Would that be 64bit color :-/

God Jul

BTW, Mr Tengelsen, that’s not one of the RO messages that needs translating. Unless there’s a winter solstice app I’ve missed.

So Mr Pampling, should we go Pagan and make the 21’st of December a Basic app which could be a small RM saying “Wavesynth Beep” when it came would be pretty nice for all Pagans of RISC OS. Bugger Archons.

Oh, and with a “Brighter Days Ahead” template thingy in the middle of the desktop thingy to make it obvious. My favorite course is dried cod in salty wind. What else is new.

Jeffery, what’s the current state of the SMB support Module and is it in a state that could be merged into the main branch?

Do the other cores have shared access to DA’s and is it possible to map overlay banks into the other cores? Migrating the VIDC20\IOC emulation in ADFFS to a secondary core should in theory be fairly trivial provided it can read DA2, write to overlay memory and write to a shared machine state area.

Reading the SMB docs it doesn’t mention what happens when an unsafe SWI is called…which got me thinking.

If SWI dispatch was SMB aware, it could buffer the SWI # / registers and sleep the thread until it next exits back to User, at which point it can unsleeping the thread and perform the SWI safely? Essentially there needs to be a means to raise unsafe SWI in a safe way until all SWI are marked as SMB safe or buffered via threads (FileCore for example) so they are SMB safe.

Another thought that occurred to me, if Appspace was independent across cores, I could run 26bit apps on secondary cores and avoid the issues caused by task switching, or even implement a full VM on a secondary core.