Thinking ahead: Supporting multicore CPUs

That is the eventual goal, yes – that standard threading libraries could make use of the SMP threading API. But the tricky part will be the fact that threads running on the other cores aren’t allowed to call non-MP safe SWIs, which is something that your average multi-threaded C/C++ program won’t be expecting.

A key milestone will be making the core C library MP-safe – i.e. everything except the RISC OS specific bits like _kernel_swi. That will mean that only the RISC OS-specific bits within a program will need to be checked for the SMP restrictions.

It may be possible to have the C library or the OS suspend threads that attempt to make non-MP safe SWI calls and reschedule them to run on the primary core. But the tricky bit is working out when the “critical section” ends – i.e. when the code is done interacting with the single-tasking area of the OS and can safely be pre-empted. For applications these rules are fairly well defined (UnixLib’s pthreads allow you to call arbitrary SWIs from threads, and task windows allow single-tasking apps to use PMT). But for modules I’m not sure if there are any safe rules to follow.

I hope to see this eventuate. It’d probably be very helpful with porting POSIX utilities to RISC OS.

The SMP build with module has been running happily since when I said I built it. No unusual errors or strange goings on.

I’ve been having some build issues recently, so I haven’t done a more up to date build yet. It’s mostly to do with files not being readable by CVS on linux, and some weird issues copying over to RISC OS.
I only discovered early this morning that most of this may be avoidable when I found a working build of gccsdk on my netbook (the gccsdk issue is a whole other story). CVS builds. So why isn’t a binary package of the current version available to download anywhere obvious?

The problem with the “critical sections” of code is one that’s been faced by OS developers since the beginning. Without some really interesting code to detect it, about the only way I can see is to make the non-SMP safe SWIs SMP safe which is of course a huge task. I guess a mutex could be used somehow to either force blocking of other threads or to mark the thread doing a non SMP-safe section of code. Even that would require lots of system wide changes, and would nuke the whole system if the program failed during some non-SMP-safe code.

Maybe I’m just talking rubbish. It’s been a long time since I’ve worked with concurrent systems design.

I was running that old build of the SMP kernel and module up until yesterday without a single crash. There was one possibly unrelated thing. Very occasionally RISC OS would get choppy. The CPU speed didn’t spike according to CPUClock. Not sure what it was but it was like something was being fired multiple times a second. I tried the SD card in the Pi B and the choppiness was also nothed there. Without the SMP module on the Pi B of course.

Last night I built the source from the day before yesterday. Like the old build I leave it running constantly. There doesn’t appear to be any issues. I’m using it now.

Unfortunately I have no comparison, but the CPU temp is hovering around 61*C while typing this. Apparently the ambient temp is about 16*C warmer outside than this time yesterday, so it may be nothing.

It’s not super useful feedback I know, but I thought you’d like to know that your code is performing well in the wild.

Unfortunately I have no comparison, but the CPU temp is hovering around 61*C while typing this.

Sounds normal, my Pi3 when left idle at the desktop goes over 60 (using the nightly build). I’m not convinced the OS’s methods to stall the CPU when idle actually make much difference, I think it’s using WFI or WFE to halt the CPU until an IRQ or event occurs in a few key places.

I downloaded the latest RO source and built the BCM source with the SMP branch and modules as of yesterday. It builds and runs fine.

Not exciting I know. Just mentioning the SMP branch still builds against the current source tree.

Sounds great. Have you done anything with it?

Besides running the test program to ensure it was sane, no. Haven’t had any time for anything in months. Downloading and building doesn’t require any real time at the computer. Just fire and forget.

I usually leave a Pi with RO running 24/7. Mostly the Pi3 unless I need programs which don’t play nice with ARMv8, or I want to use the DAC card.

Beyond the occasional choppiness I observed with a much earlier version of the SMP branch, nothing untoward has happened which I consider a good thing.

Pretty much it’s just sitting waiting for me to do something.

Just a thought… Not ideal but could we have a marker you could add to program dir that says its a stand alone program so that things like say a music/mp3 player could sit on its own core and somehow as soon as app tries to pass control on hand it straight back to all almost..

However, also add an api that could be tapped into for true multicore processing. Kinda similar to Hydra in this respect as it had an api. So say for example the guy who had the prime search app wanted to he could tap into the extra processing available.

The problem isn’t really what core something is running on, the problem is the issue of reentrancy. There are a number of parts of RISC OS that were designed with the assumption that it’s a single user single process system (it is – the multitasking is clever shuffling of memory mapping). This creates various issues in a SINGLE processor setup where, for example, doing file operations in a ServiceCall or on TickerV can cause things to go awry. Now imagine what would happen if multiple cores were trying to do stuff. It could all go horribly wrong, aaargh!
Okay, that was hammy. Fair enough. It isn’t impossible, a mini OS could run on the other (non-primary) cores and marshall requests for resources back to the primary RISC OS to deal with when it can. However, if doing so becomes a bottleneck, then I’m not sure if such an application would really see much benefit over just running the on the primary core like it does now.

I suspect that other-core apps will need to be specially written to be aware of the issues around using another core (something that crunches numbers might be a good candidate? anybody up for porting the slow-as-molasses ChangeFSI? ;) ) as opposed to just any arbitrary application. Your music/MP3 player example, will require a constant stream of data in (internet or file) and a constant stream out (audio device).

There was actually a mandlebrot software released with hydra (no idea if source code was released but think it was supposed to be). And full documentation of api and its use. Wonder if we could actually create the same api but for the extra cores in modern chips. Ok it will be more work as imagine some of hardware logic on hydra board may need to be taken care of in api itself .

I still think as an 2nd part its sensible to look at small apps that could do with ability to run in background a music player was my example as its one of few that have a tangible benefit from being able to get on and do its think while your doing other stuff. It’s a good start that could maybe lead to say parts of OS itself being run by one core and apps on another.

To be fair, Option 1 seems to be the most viable but the least RISC OS’y, maybe a compatibility mode could be implemented to ensure that software won’t need fixing?

How about using GCD?:

https://en.wikipedia.org/wiki/Grand_Central_Dispatch
Quote: “…
The source code for the library that provides the implementation of GCD’s services, libdispatch, was released by Apple under the Apache License on September 10, 2009.³ It has been ported⁴ to the FreeBSD 8.1+,⁵ MidnightBSD 0.3+, ⁶ Linux, and Solaris.⁷⁸ Attempts in 2011 to make libdispatch work on Windows were not merged into upstream.⁹¹⁰ Apple has its own port of libdispatch.dll for Windows shipped with Safari and iTunes, but no SDK is provided.
…”

Sep 1, 2009, Mac OS X 10.6 Snow Leopard: the Ars Technica review.
Grand Central Dispatch.
https://arstechnica.com/gadgets/2009/08/mac-os-x-10-6/12/
Quote: “…
The bottom line is that the optimal number of threads to put in flight at any given time is best determined by a single, globally aware entity. In Snow Leopard, that entity is GCD.
…”

Using Grand Central Dispatch on macOS:
https://apple.github.io/swift-corelibs-libdispatch/tutorial/
Quote: “…
This is where GCD steps in to lighten the programmer’s load. GCD works with the Operating System to keep track of the number of cores available and the current load on the system. This allows a program to take the best advantage of the system’s hardware resources, while allowing the operating system to balance the load of all the programs currently running along with considerations like heating and battery life.
…
Before examining the GCD library routines and data types, let’s take a moment to look at the basic units of code you will be defining. GCD works equally with functions and blocks as the work units that you give to GCD, which in turn dispatches their execution on various threads.
…
GCD helps you gain performance when you can split large programming tasks into smaller operations that can run independently on multiple cores. It’s often necessary to know when several independent operations have completed. That’s the purpose of dispatch groups.
…”

How about using GCD

In keeping with the quirky nature of RO any such port would need to be labelled NewStreet or SnowHill (depends on the separation of the result from GC) :)

JavaScript and I think Dart are single threaded languages; to work around this and allow the use of extra CPUs; they both have a concept of isolated web workers, a web worker can not see or modify any shared state; it just runs scripts on another thread in a completely isolated instance and communication is by messages only.
Something message based like that might work for the Wimp to use other CPUs; an app could send a message to a worker (managed by the small OS on the other core); and the worker would send a message back to the App via the Wimp message system.
Probably this idea was dismissed a dozen pages ago :)

In keeping with the quirky nature of RO any such port would need to be labelled NewStreet or SnowHill (depends on the separation of the result from GC) :)

Sounds more like Clapham Junction to me…

Sounds more like Clapham Junction to me…

Er, no.
You see, with strange and (possibly) mildly amusing comments you sometimes need to do a web search for combinations: like Grand Central and New Street

I could have mentioned Moor Street rather than Snow Hill, but that’s less well known and of course Curzon Street doesn’t currently exist (except an old remnant) but should HS2 actually get completed…

Just use CoPilot to write (most of) your (Risc OS) code – whether in ARM64 assembler, C, C++, C++20, BBC Basic, Pascal, BCPL, Forth, Logo, PROLOG, Javascript, JSON, Perl, Python…:
https://copilot.github.com/

Just type RISC OS 6 or 7 or 10 and multicore? It may autocomplete the code to your next Risc OS – it is flawless AI :-] But DO NOT type skynet, that will jeopardise our whole civilisation :-(

Maybe copilot will some day be standard in our (Risc OS) IDE?

Just use CoPilot to write (most of) your (Risc OS) code

No thanks. Around here we don’t tend to have the concept of copy-pasting random rubbish from StackOverflow and hoping it works. So we sure don’t need a tool to regurgitate random bits of (mostly) GPL code ¹ that it thinks might be the solution the programmer is looking for…

¹ That appears to have been its training set.

Just use CoPilot to write (most of) your (Risc OS) code

Ahh, yes, the shining bastion of code…

As part of my attempt to re-write the kernel in C, I’ve included multi-processing. It’s at a very early stage, but the cores have some independent storage which allows modules to provide services simultaneously on multiple cores. The current state is that one core gets an abort and stops, the other three rotate their cogs, but the output flickers due to cache cleaning problems (turning off the cache for the screen memory avoids the abort (!) and makes them flicker for other reasons).

https://www.riscosopen.org/forum/forums/9/topics/16166

Wow. This conversation has gone on for a very long time! I must apoligize, I’ve only read the first 100 mesages and the last 100. I hope this isn’t repetitive.

I came to RISC OS from attempting to use linux on a Raspberry Pi Zero for a project. I was very annoyed by the the performance and switched to bear metal programming. With that, did some tech searching of what was out there. FreeRTOS — the most popular RTOS, is simply sloppy. Keeping it short, I was starting my own and then came across Embox. The build mechanism and modularity of this RTOS is impressive. It is POSIX compliant, it is very capable for build from source incorporation of 3rd party projects. It has a wide range of various ARM targets and x86 targets.

For RISC OS and the multi-core challange, for the multi-platform challenge, I’m thinking it may be a very good fit for Options 2 and 4. Specifically, I’m thinking Option 4 first but also supporting Option 2 with more SWI calls for multi-processor services.

I’d like to see the simplicity and openness of RISC OS retained in an un-disturbed environment. A gradual move of drivers (window manager/video, keyboard, mouse, serial? must be done first) to the RTOS environment kind of approach. I’m thinking old drivers stay as they are, new drivers are added that are thread-safe that exist along side the old ones. If a new driver is used, it would block the old one? I suppose.

I noted Acorn considered Mach in the past — I like the way they think! I’ve always been a fan of Mach, I’d built a 5,000$ 486 machine back in the mid-90’s to run NeXT (then the memory prices dropped! It was 32Meg.). I’d think give that a go but honestly, the seller for me is the build environment in Embox. It’s modularity is un-surpassed. You get to use make, cmake, and you get the features of NuGet without using that too (even better than NuGet even)l. Honestly, check it out if you’re not familiar with it.

Multi-core WIMP thread.

Think of it as four computers running RISC OS and cooperating to share resources.

That’s good :)

An abstraction springs to mind, a hypervisor with separate virtual machines running simultaneously, each Virtual Machine (VM) supporting inter-VM-application protocols. A model like this could potentially support 8 bit, 16 bit, or 32-bit applications; consider how the DOS-based PCEmu worked within RISC OS.

I wonder if this approach could smooth the transition to a secure, multitasking, 64 bit RISC OS kernel, coupled with a new compositing window manager.

A benefit that springs to mind, old applications continue to run with partial sandboxing and an inter-VM-application protocol. ;) Food for thought or way too complex?

An abstraction springs to mind, a hypervisor with separate virtual machines running simultaneously, each Virtual Machine (VM) supporting inter-VM-application protocols. A model like this could potentially support 8 bit, 16 bit, or 32-bit applications; consider how the DOS-based PCEmu worked within RISC OS.

Why not expand that to a cluster? [tosses grenade and ducks for cover]

A Pi cluster :)

This is the sort of Pi cluster I prefer: https://www.piesbypost.co.uk/collections/meat-pies