Multicore template for ASM code?

Look here:
https://www.raspberrypi.org/forums/viewtopic.php?f=55&t=99747&sid=48bfc49c6fdd942f650bcbd6f61ffd0f

It seems that multicore code made for bare metal ARM assembly can be adapted for RISC OS.
I see some problems with it, since L2 cache and memory are managed by RISC OS. And it’s complex for non system developers (as me).

Could I suggest a template to convert some ARM code to ready to run code for core 2,3,4 (Pi2/ARMX6) or 2 (Panda), with the right parameters to allocate memory (inside a DA?), share data and manage L2 cache? Of course a module that will manage that (send AOF code to it and let it manage all, including ‘core in use’ messages) would be fantastic, but a simple template would be a first step to use this feature. At least.

For example, I would use it for arithmetic evals in free precision. I see things like this: I have small AOF code. I launch it through a module that will send it to one available core. If none are available, task will be launch in a taskwindow. Address of my code in memory is returned to me. When I’ll use shared memory to interact with my AOF code from the main application. A SWI call is available to kill the code if crashed.

A quite complex module, but seems to be possible, no?

For myself, and I guess this goes for most of the RISC OS community, my only experience and knowledge about programming is about serial programming. Parallel programming has been the preserve of a select few in academia or research centres. Until recently there were no opportunities, it seems to me, for the amateur to play with parallel systems.

The only programming languages that have been advertised as appropriate for parallel programming are functional languages, such as Haskell, in which the ordering of components of the source code is entirely decoupled from order of execution. But these languages have never been popular with amateurs; nor as far as I know with the general run of commercial programmers.

I’ll use shared memory to interact

Interrupts also will be needed to tell the main program when parallel computations have terminated and the answer is ready to be read.

There’s an interesting comment in that thread, for anyone with a Pi2

Your bare metal environment doesn’t wake the other cores up, which means they keep polling a register, and so compete on the bus with the useful work you want the first core to do.

and

using config.txt option arm_control=0×1000, changes the “cmp r0, #0xff” to be a cmp r0, #0×1″, which causes the secondary cores to not poll for the signal, but just to sleep.
This was obviously just a debug switch when trying to get multicore linux working, which fortunately hasn’t been removed yet.
The real solution is for your bare metal world to wake up the other cores and make them sleep, or change the bootcode to sleep directly.

From which I take it that there is a bit of mileage in RISC OS users adding that option to their config.txt file. Don’t know how much is changed. I wonder if other multi-core ARM chips have the same feature?

Don’t have a multicore board to test myself.

From which I take it that there is a bit of mileage in RISC OS users adding that option to their config.txt file.

Sounds like it.

Or alternatively it’s a good excuse for us to add some basic multi-core code to the HAL ;-)

I wonder if other multi-core ARM chips have the same feature?

It looks like OMAP4 & OMAP5 leave the other core(s) in a WFE loop (i.e. low-power sleep state). The cores can then be woken up by writing the start address to a (OMAP-specific) register and executing a SEV instruction.

For the Pi, it looks like you have three choices:

• Default behaviour has the GPU wake up the cores and put them into a busy-wait loop (polling a hardware register until it gets written with the core boot address)
• Or you can use arm_control=0×1000, in which case the cores will sit in a WFI loop with no possibility of exit
• Or you can use kernel_old=1, which looks like it might result in all four cores executing the ROM image, requiring the HAL to do some extra hardware initialisation and put to sleep all but one of the cores?

If there was a WFE in their busy-wait loop then everything would be fine (although it would obviously break any current code that doesn’t issue SEV after writing the boot address!)

From which I take it that there is a bit of mileage in RISC OS users adding that option to their config.txt file.

Sounds like it.

Or alternatively it’s a good excuse for us to add some basic multi-core code to the HAL ;-)

Well, if you’re looking for work :)¹

But the bootloader tweak looks like a quick test.

¹ Although I suppose the multicore work does have to start somewhere and stating the obvious the HAL is (almost) right at the start. I was thinking the simple bootloader test should reveal a few things.

Parallel programming has been the preserve of a select few in academia or research centres.

I think more or simply pushing some ‘calculation only code’ to other cores. Not // code, but only move code from core 0.

For example, it would be fun to be able to say that ASM code in Basic will run on core 1 and not core 0 (of course, no SWI calls). If we have callbacks, it’s even better (for a kind of ‘multithreading’), or async run.