Thinking ahead: Supporting multicore CPUs

Then anything which really needs/benefits from 100% CPU time

I don’t see that as any kind of problem, considering that what legacy applications would expect from “100% CPU time” is rather different from what modern hardware can deliver.

I’d also like to quibble slightly about terminology, because multi-core (or threaded) support is not the same as a pre-empted Wimp. These concepts are orthogonal – you can have a pre-empted Wimp in a single core (Wimp2), and multi-core support with a co-operative GUI (Hydra).

I think the question which best sums up the “100% CPU time” question and the requirements of actual legacy programs is this: What does F12 do in a multi-core system? That’s a more profound question than it may appear at first sight.

What does F12 do in a multi-core system?

Opens a TaskWindow.

I’m not being facetious – there’s no sensible way to support such a thing without inordinate amounts of work. Using Windows as an example, ever noticed that your anti virus pop up appears on top of your single tasking DOS program? What happens if you are playing Quake and hit the windows logo key by mistake? The command line is “just another program”, one that has the right to use the entire screen, but it is far from single tasking.

I think the point Andrew is making is that we should abstract ourselves as much as possible from the mechanism of assigning threads. We used to programme microcomputers in assembly language, but long ago moved to high level languages for almost everything, because the abstraction makes us more productive. We should do the same for threading.

What does F12 do in a multi-core system?

Opens a TaskWindow.

So what does <Ctrl>-<F12> do? ;-)

I would not use a RISC OS that did not have an F12.

Hell, even my BranchThroughZero handler has its own command line loop, I’m not losing the desktop one.

That’s a reasonable objection nemo, the ability to quickly drop to the command line is something quite useful with RISC OS; especially since no task window client even remotely approaches the flexibility that F12 offers, especially when it comes to debugging complicated stuff and you want to work your way around with as little outside interference as possible.

I think ShellCLI should be made harder to get to, we really ought to consider a transition to an in-GUI command line; however I think to lose it entirely would be to the overall detriment of RISC OS.

That said – I’ll throw it back to you. How does one support multiple cores while in the shell? The cop-out answer is to suspend the cores not running the shell, but one would be forgiven for thinking that multitasking could continue in this situation. Or, worse, the nightmare scenario of the program being run from the shell wanting to use “threads” (I use this term extremely loosely to save a technically accurate but stupidly lengthy alternative….which might have been more convincing if not for the stupidly lengthy bracket-comment written instead…um…) on a system that might already have those other cores in use (active or suspended) from the Desktop.

And since all of that involves units of processing managed by the kernel, we’ve a good chance that use of all the machine’s resources will be appropriately balanced from moment to moment.

Would this extend to tasks themselves? So when a program is called (return from Wimp_Poll(Idle)), it can run on whichever core is available or the least laden at that moment in time? We might have some performance niceties if we can divvy out the work and have the Wimp capable of multitasking as many tasks concurrently as there are cores available. ;-)

[note to self – file this in the wish list forum]

How does one support multiple cores while in the shell?

What’s so hard about it? You have three basic choices available:

1. Suspend the Wimp, and actively suspend the threads (or code blocks, or whatever you want to use) of the tasks to guarantee that they stop.
2. Only suspend the Wimp, i.e. make it stop sending events to tasks. Most tasks will then naturally go into a dormant state as they sit in Wimp_Poll waiting for something to happen.
3. Allow the Wimp and its tasks to continue running, but treat ShellCLI as a full-screen window that is always ontop so that nothing (apart from stuff playing sounds in the background) can appear to interrupt it.

Option 1 is basically what we’ve got now. Option 2 would allow some tasks which are performing background processing (printing, downloading files, video encoding, etc.) to continue to run, as long as they’re written in a fairly sensible manner (i.e. won’t keep adding requests to a queue and then run out of memory because the thread waiting on Wimp_Poll isn’t servicing them). Option 3 is basically what Windows does, with varying degrees of success (No, Windows doesn’t have ShellCLI, but it does still support entering a full-screen “single tasking” mode, e.g. playing full-screen games)

I think it’s 3, but not quite as described. We’re inventing nothing new here; Amiga’s Workbench had screens from the start. That’s what we’re describing – at the F12 prompt, you’ve essentially just created a new screen at the horizontal split point.

On modern graphics hardware this simply equates to painting into different surfaces.

Jeffrey asked:

What’s so hard about it? You have three basic choices available

No one said it’s hard, but it was undefined.

Andrew replied:

at the F12 prompt, you’ve essentially just created a new screen at the horizontal split point.

And that’s were we part company. I wouldn’t use an RO that worked like that. The value of F12 to me is that it does stop all tasks running. Just like having a CLI on BranchThrough0 and AddressException handlers, this allows the developer to get out of difficulties (often but not always) of his own making.

I usually press Ctrl-F12, but when I press F12, I mean it. There’s a lot to be said for being able to kill an errant module or task from the command line.

There’s a lot to be said for being able to kill an errant module or task from the command line.

And how would leaving those tasks running, instead of suspending them, change that?

If we’re looking at at properly multithreaded, multicore aware RISC OS supporting a high level API for such, along with a preemptive WIMP, then there must already have been substantial architectural changes including the ability to kill a module whenever you so wish while acknowledging the consequences (so we move beyond those things which can cause, for example, Filecore In Use, to the benefit of all; the very rough equivalent of “sudo rm -f” on some important in-use library). As for killing tasks from the command line, surely that’s easier from the Wimp (Alt+Break) but in any case it’s the pre-emptive Unix which provides “kill” and “pkill” from the command line, not RISC OS!

In short, whether or not a task is running should have no bearing on whether or not it can be killed.

As far as debugging is concerned, in a preemptive environment once again all debugging mechanisms would have to be substantially upgraded.

Even so, if RISC OS had “proper” processes and the concept of process ownership then it ought to be easy enough to ask the kernel to suspend (halt) all processes own by and including the Wimp, which amounts to what you describe with F12 (since all other background interrupt based activity does of course continue, even under F12; it’s only Wimp task switching that halts; callback triggering may be complicated).

In short, whether or not a task is running should have no bearing on whether or not it can be killed.

Yeah I’d like to live there too, sounds like a nice place. Meanwhile back on Planet Earth, there’s a large difference between the OS being stable and the OS being stable while being called incorrectly by confused/broken/malicious tasks.

If you can deliver a cast-iron OS that is capable of running a functioning command line while pre-empting tasks that are generating exceptions constantly then yes, you can allow them to continue running while you set about killing them. As it is, that’s a vain and frankly unrealistic hope.

so we move beyond those things which can cause, for example, Filecore In Use, to the benefit of all

And the dreaded long-standing MessageTrans misdesign I’ve previously mentioned. But it doesn’t stop there. Anyway, the ability for the developer or power user to stop it all with a keypress is a luxury I would not give up, and the ability to manually kill modules, load new ones and reconfigure stuff without tasks noticing is also very valuable.

Forgive my scepticism, but do find the prospect of a bomb-proof RO somewhat less likely than the ability to use additional cores via a Worker model. Depending on the limitations of that model (ie, if Hydra- or Tube-like) then RO doesn’t need to become thread safe or re-entrant at all. That might sound like aiming low, but I’m pragmatic.

Ok. Ok.. integrating multiple CPUs within RISC OS does not sound like something that we can sort out due to numerous reasons. So what about a sandbox where the extra CPUs can run code in their own safe environment and have it ‘chat’ with RISC OS using a device or messaging interface? Offloading specially demanding tasks like video, audio or even background processing should be possible that way, right?
It would at least provide a way to experiment with extra CPU’s and help learn how to deal with it from the RISC OS side.

So what about a sandbox where the extra CPUs can run code in their own safe environment and have it ‘chat’ with RISC OS using a device or messaging interface.

Already discussed this option – the one where RISC OS runs in core 0 and a mini OS runs in core n which deals with real simple stuff for itself, and anything else is passed over to the OS on the main core. There is precedent, from the Beeb co-pro (any, Tube worked the same way on all of them) to a very simplistic view of how the x86 co-pro in the RiscPC worked.

I do foresee something like this happening, though the worry might be that if something like that gets established, will RISC OS have missed its chance to support multiple cores?

The trick is – don’t place bets; but equally don’t give up hope. RISC OS died with the RiscPC…. Er… There will never be a 32 bit version of RISC OS, we will be stuck with antiquated… Er… RISC OS is officially dead, the Iyonix is no longer… Er… We’ll never see RISC OS on a board clocking a gigahertz with half a gig of RAM on board… Er… Play with RISC OS’s source code? You’re having a laugh, right? Er…. RISC OS available on a computer kit cheaper than a mid range calculator? Impossible! Er….

It’s great fun for the doomsayers to predict how the platform will crash and burn and we’ll all jack it in and install Debian instead. Thing is, they’ve been wrong. Either that or RISC OS has more lives than a cat, and possibly more than a Time Lord.
So I believe that, some day, RISC OS will offer multicore support, most likely transparently to most apps. Because one day boards with single cores will be like “Dude! Really?”. I’m not entirely certain that little.BIG (or whatever ARM call it) is the way forward, however it must be clear that multiple cores is. When there is a pressing need, RISC OS will probably adapt, just as it has for its selection of devices up until now. Just….don’t hold your breath or anything. ;-)

I do foresee something like this happening, though the worry might be that if something like that gets established, will RISC OS have missed its chance to support multiple cores?

No, because the limited-expectation model does not preclude greater capabilities later. eg a program that thinks it’s running in a Tube with a handful of SWIs available to it can run under a full OS later (and obviously would be doing so on a single-core system from day one!).

Ok, again..
Still we need a sandbox first. Nothing will happen from arm-chair philosophy if noone is doing the hard work to get things started.
I have plenty multi core devices/boards that would be suitable but only one that already runs RISC OS. The Panda board. So if we can get Panda to bootup the second processor within a restricted memory space and have a ‘shared memory’ area to interface to it we are set to go. Simple graphics demos or just offloading computations should be possible with that. Technically it should suffice to write a module for that I think.

For the sandbox idea, I think it could be easy (edit: at first glance) up to SWI level: maintain a secondary chain of modules which only modules flagged as “thread safe”. Processes for old cooperative CLI/Wimp applications get the full chain when switched in, new processes the sandbox chain so they don’t see the non-thread safe SWIs and commands. Only a single old type process can run at a given time, but there is no restriction on new types which can run in “parallel” even with old types has the only code overlap is “thread safe”.

So the basic steps would:

• centralize in a module the management of processes with the minimal interfaces required to manage the old tasks Task_CreateOld(), Task_Yield(), Task_Destroy(), Task_SetEnv(). Update the modules currently managing tasks (Wimp, CLI?, TaskWindow?) to use these calls, build a test version and check if the system continue to work normally.
• add minimal support for new processes: a Task_create() function, “thread safe” a few modules (UtilityModule, FPEmulator, …) and create the sandbox module chain, extend processor state saving (VFP, FPE, NEON), add time-slicing multitasking paying attention that on switch if curr_old_task <> 0 switch only to new task type or back to curr_old_task else switch is to any task, and on yield reset curr_old_task to 0 if that task is yielded. Build a test version and create a few test applications of the new type (no IO, just performing calculations and saving intermediate results in a shared memory area so that we can check that work progresses in the background).
• add support for multiple cores and build a new test version.

From there development order becomes less important:

• add support for sub-processes, threads or unit of works or whatever model you decide to implement.
• iteratively thread safe modules and build test versions. At that point I’d start with basic standard output modules and think about task contexts. Next would be IO modules, Filecore and FileSwitch but here you have modules which registers handlers to other modules and so you could register a non-sandboxed handler to a sandboxed module. Sandboxed modules must thus know if the registration was made from a old or new type process and must behave as if the old type handlers do not exist when called from a new type process.

100% OK. Make a basic SMP setup with RISC OS inside one core. And then go on with no I/O code (step 1) and all the other code (step x). To be able to use the other cores for performing calculation would be very useful (for me). And not incompatible (later) with a full SMP system. I currently work on a Basic dialect that would love to get this feature :)

When re-reading my last post, it occurred to me that if we except multicore support, every step could be developed first on a branch of the IOMD and tested with RPCEmu first without the need to recreate a boot every time, plus more people would probably risk trying alpha versions on such a system.

bump.. We’re march 2014 by now and even a sandbox has not been realized.
At this pace we’ll be old and grey before any multi-core effort has been launched.

Jan: Is there MPCore support built into the OMAP4 build? ARM’s documents appear to have the code needed to switch cores in their documentation.

Being able to actually switch the cores at all would be the very best start.

We’re march 2014 by now and even a sandbox has not been realized.

Thank you for volunteering. I have a day off next Friday so will be happy to test your multi-core sandbox code…

(^_^)

ARM provides code that permits to set up an AMP system. So it should be possible to launch two sessions of RISC OS on the same computer, without much changes. In a way, to have a small RISC OS kernel on the second core, ready for calculations, would be a great step forward for me (and really enough, from my point of view). As I already said, I can pay for that (I’m not really good with kernel things).

A lot of people would like to get SMP support in the RISC OS kernel. But it will need so much changes that I’m not sure that the result would not be simply a new OS :)

Anyway, there are ways to get a good support of multiprocessor configurations, with three steps.

1/ Make the OS works in AMP mode. Needs a few lines of code at boot, and – normally – no change. Provide space for the other cores (reserved memory & shared memory). Provide a monitor to control the cores and send them tasks. This is possible. In fact we did have this kind of AMP configuration a long time ago: RISC PC + PC Card.

> This point needs PandaBoard for code and tests.

2/ Revive WIMP2. WIMP2 was working quite great. It provides preemptive multitasking inside WIMP, with support of applications that needs to work in cooperative mode. May I suggest to put this module below the WIMP? It would be very useful for people who want to make a multitasking CLI application (robotic, web server, etc.).

> This point can be made on every system.

3/ Add a preemptive multitasking monitor to the other cores. Make this processing power available from the main core with light threads. integrate this support to a future WIMP3.

From this point we would have: preemptive multitasking in WIMP, with fallback to cooperative mode when needed; preemptive multitasking services for CLI applications; light threads to access the power of all cores (but still no threads or true SMP mode).

If it’s possible to activate memory protection on Wimpslots, it would be great. Too much system crash from Wimp applications :)

Bounty?

I remember that many applications works well with WimpPatch. Would it be a good idea to simply implement a “force to call Wimp Poll” inside the system and to see which applications refuse to work?

The idea would be to keep the existing code (after all, if a task give back the control by itself, it’s good) and set a timer to force the switch (save state of current application, load state of next one and call of the standard polling system. nothing else). Apart from the tricks, it was the way Wimp2 seemed to work.

For tests it could be also possible to stop the timer, and so the preemption. Or even to use different timer (<1ms) to get an hard RT system. Or perhaps a mix of the two systems (if the current task is not on the list, don’t stop it). Preemption on demand :)

Nota: I’m perhaps completely wrong as I’m not an ASM expert, but it seems easy to make: first, use HAL_Timer to call a task in user mode (needed to call Wimp polling system). When called, looked at the current running task. Is it inside the preemptable list? No > set new timer and leave. Yes > save its state (and some information needed to Wimp), load save state of the next application (nothing if it’s a cooperative only one), set new timer, call Wimp polling system.