Thinking ahead: Supporting multicore CPUs

Yes, that would work. But with most things software related, it’s not a question of whether it would work, it’s a question of how much effort is required to make it work, and who is willing to undertake that effort

But I had to ask the first question first!

The next questions, as you say, are ‘how much effort is required to make it work?’ and ‘who is willing to undertake that effort?’

Malcolm: JIT isn’t always to do with Java. https://en.wikipedia.org/wiki/Just-in-time_compilation

RPCEmu has a JIT compiler that translates the ARM instructions into x86 or x64. What would be needed would be an equivalent version for ARM, which unfortunately isn’t as simple as copying the input code directly to the output buffer ;-)

ARM on ARM is fairly simple to implement, the complication comes from supporting CPU control registers, emulating/virtualizing the chipset, CPU pipelining, rotated memory access and self-modifying code. Not to mention the differing requirements of each CPU around TLB and cache maintenance.

The alternative, to avoid the issues of trapping memory accesses outside of the codespace is to implement a partial JIT that emulates all memory access instructions.

JIT isn’t the only option, if you’re not going for speed then an alternative is to execute the original code replacing problematic instructions with hypercalls or breakpoints, which are then emulated.

Having said all that, a simpler solution would be a Hypervisor and just spin up a VM running full Linux. Unfortunately RISC OS isn’t currently capable or running a Type 2, so you’re then looking at a Type 1 – which currently wouldn’t support RISC OS as it has very specific hardware requirements.

I hoped it was java, I have enough of an idea of how a jit works to know not to attempt it. I’ll see how nasty it is without it. I’m guessing it ain’t going to build.

To make it work you’d probably need more Linux knowledge than RISC OS knowledge (custom kernel build, root FS, etc.)

And as Linux is not an AMP kernel, you would need some hardware abstraction layer (KVM, RPCEmu, whatever) around it. Big job.

emulating/virtualizing the chipset

Yep, so you need a virtual hardware behind ARM on ARM, as QEMU is behind KVM.
First step would be to have a generic emulator (the QEMU part), before thinking of speed (the KVM part).

RPCEmu… or an ARMv6/VIDC20/IOMD2 version of ArchiEmu? (IMHO, it’s a better choice).

Having said all that, a simpler solution would be a Hypervisor and just spin up a VM running full Linux.

True

Unfortunately RISC OS isn’t currently capable or running a Type 2, so you’re then looking at a Type 1 – which currently wouldn’t support RISC OS as it has very specific hardware requirements.

Yes and no. QEMU (behind KVM) has now a Raspberry Pi 2 mode. RISC OS does not boot on it, but could perhaps with some efforts. Result: RISC OS will work on any forthcoming ARM server solution. RISC OS on the Cloud :)

And since QEMU is available on almost any OS in emulation mode, we would have too a good alternative to RPCEmu for RISC OS 5 systems.

QEMU (behind KVM) has now a Raspberry Pi 2 mode. RISC OS does not boot on it, but could perhaps with some efforts.

Have you reported that to the QEMU dev team? The fact it fails implies the BCM2835/BCM2836 emulation has an issue.

I’ve not tried QEMU since MS got involved in the BCM emulation, but have had RISCOS 5.21 running under it previously. Although the desktop worked okay, ADFFS failed to work, which was my only reason to use it.

Would ArcEm be a better bet to get running on a Pi/Linux?
Can you run RISC OS 5.x on ArcEM? (note, not should you!)
I see “some-one” is applying their dark magic on it :-D

As far as I’m aware, ArcEm specifically emulates an Archimedes-class machine and therefore won’t run anything newer than 3.11.

Yeah, ArcEm is just for emulating Archimedes machines. There’s no JIT, but I did spend a fair bit of time optimising the interpreter, so I’d expect it to run better than RPCEmu. However there’s no network support, so if the aim of the exercise is to allow the use of wifi then it’s not really suitable for the task.

Back on the subject of multicore, I’ve come to the conclusion that the best course of action is to effectively put the multicore development on hold while I sort out the OS’s approach to cache maintenance. There are too many issues (some little, some big) with how it currently does things for a safe SMP setup to be possible.

the best course of action is to effectively put the multicore development on hold while I sort out the OS’s approach to cache maintenance.

I (perhaps mistakenly) assumed your cache investigations were part of the pre-req work…same goes for the way memory is mapped/released.

Slightly off topic again…Regards the whole QMU/KVM/Pi Virtualization to make use of other cores, I tried QEMU 2.6 yesterday and couldn’t get it to boot Jessie, let alone RISC OS. On the CPU side it’s not complete and on the hardware side it’s missing at least USB. It looks like the MS involvement was unsurprisingly to get Windows 10 booting, which was achieved, so it’s unlikely to see much further development.

It would probably be quicker to extend RISC OS support to the ARM development board that just about every Hypervisor supports and use a Type 0 Hypervisor such as Xvisor!

the best course of action is to effectively put the multicore development on hold while I sort out the OS’s approach to cache maintenance.

I (perhaps mistakenly) assumed your cache investigations were part of the pre-req work…same goes for the way memory is mapped/released.

Investating it was part of the pre-req work, yeah. But fixing it was something I was hoping to avoid (at least for now) since it opens up a whole new can of worms :-)

It looks like the MS involvement was unsurprisingly to get Windows 10 booting, which was achieved, so it’s unlikely to see much further development.

Knowing the things MS do their contribution probably adds to the incompatibilities with other OSes and the linux boys don’t care because they will just twiddle linux a little more on the basis that it’s a weird ARM chip rather than a naff emulation.

I have an odd idea for this venerable thread.

I wonder if Xen could help? It’s a FOSS hypervisor. It works by having a “master OS” in one “domain” — VM — and guests in the others, and for CPUs that lack full hardware virtualisation, it supports “paravirtualisation” where the guest is modified slightly so that it knows it’s running in a VM. It supports ARM already, and the Raspberry Pi 2 & 3 at least have the support — the snag is that they don’t have a virtualisable global interrupt controller. I don’t know if paravirtualisation could get around that.

https://en.wikipedia.org/wiki/Xen

Xen boots first, then the main OS boots in dom0 — the master VM. This would have to contain a full instance of RISC OS. Dom0 starts all the others. The guest domains would hold very cut-down instances of RISC OS, akin to RISC OS Pico: no filesystem (perhaps do it over a network, with a read-only view of the boot volume), no taskbar, no window management — each window is the whole desktop as far as that VM is concerned. There would need to be “stub” modules to pass some calls to and from dom0 so guests got a taskbar icon and so on.

It would not help in creating multithreaded RO programs, but it would allow a multi-processor machine run as many RO apps as it had cores, all at full native speed. It would also be an indirect way of bringing pre-emptive multitasking to RO. Some apps wouldn’t be happy sharing, I’m sure, so they’d have to run in dom0. Better-behaved apps could run in guests.

There wouldn’t be a lot of interprocess communication, but it could be done via a virtual network filesystem — perhaps held in a small RAMdisk in dom0.

Basically, you describe here an AMP system. Could be done (without Xen), when cache maintenance problems will be solved.
I think too it’s the right short term solution to use other cores.

It’s a shame Ultibo core is Pi specific and probably has licensing issues. I believe it handles multiple cores, and uses multithreading.

WIMP 2 Kind of worked. At least it showed that it was possible to use pre-emptive multitasking with graphical applications. That’s really a good part of the battle already.

Multitasking CLIs use pre-emptive multitasking too as you know. I believe it has been said many times is the real issue is that WIMP handles the co-operative multitasking. So really wouldn’t the first step regardless of backend is to try to shift all of the multitasking out to a coherent module?
As far as I’m concerned even if this hypothetical module (or whatever) had the WIMP multitasking code and lower level pre-emptive code grafted into it so at least everything is in the one place, it would be a massive step in the right direction even if said code still ran as it did previously.
It would allow, at least in the beginning, for the WIMP co-operative multitasking to sit there as a thread, or process (again whatever), so chug along as before, along with the other processes.
It would allow the development of a common set of APIs / level of abstraction to make the pre-emptive kernel functionality more or less irrelevent.
From there, whatever core could be implemented and eventually the WIMP code could be rewritten to allow WIMP processes to run as fully fledged processes instead.

I may just be spouting crazy talk here, but it’s about the only way I can see of pulling out the table cloth without leaving a mess on the floor.

I keep seeing mentions of AMP popping up here every now and then and I was wondering, are there any examples of such an OS/Architecture still in use?

Amiga OS.

AMP is not transparent, as your tasks must manage it. The same way, CMT is not bad, but your tasks must manage it.
As with PMT, SMP is transparent. But it implies much more work to avoid the giant lock. And to adapt applications too.
I’m not against PMT or SMP. But if old applications don’t work any more, RISC OS will not be RISC OS any more, but a new OS, with a new ecosystem to create.

That’s probably the reason why Amiga OS opted for AMP and not SMP.

I’m not against PMT or SMP. But if old applications don’t work any more, RISC OS will not be RISC OS any more, but a new OS, with a new ecosystem to create.

That’s exactly my concern. I sincerely doubt it would gain any traction. A computer that has an OS with no applications is an expensive paperweight.
Anything that is done has to have minimal impact on the end user.

You’re making me think here. I might have to dig out my textbooks.

Both PMT and SMP can be implemented in a way that keeps backwards compatibility so that in itself is not an argument one way or the other, it’s been done at least twice already (Windows & MacOS). Not saying it’s easy but if people want more software built for RISC OS then making it more complex to write is hardly the best way forward.

Wait, when did Amiga OS even adopt multiprocessing at all? Apparently it’s being worked on, but…

In any case, Mac OS 8.5 and earlier were clearly AMP, it got fuzzier in 8.6 through 9.2 (I would argue that those were a SMP kernel running an AMP userland).

Wait, when did Amiga OS even adopt multiprocessing at all?

maybe in 1997, AMP PPC and 68k : https://en.wikipedia.org/wiki/PowerUP_(accelerator)

The link is slightly broken, but clues enogh to get there.

PowerUP kernel is a multitasking kernel developed by Ralph Schmidt for Phase5 PowerPC accelerator boards.⁹ The kernel ran alongside the AmigaOS where PPC and 68k native software could run parallel.

So basically Amiga OS didn’t. However, PowerUP kernel allowed AmigaOS to see PPC and 68k software running on the same box.
Sort of like the add on x86 card on software for the RISC PC which somewhat pre-dated it?

So does that get claimed as parallel processing? I’m going to go with “not really”

So does that get claimed as parallel processing? I’m going to go with “not really”

A rudimentary definition of parallel processing is where a process is split into parts that are executed simultaneously on multiple processors within the same computer.

Within this definition, running DOS or Windows on an attached PC card is “parallel” in that it is code hosted on the same system in the same memory running on two different processors, but as it is completely different and unrelated code on each processor, it fails the test.

However… Didn’t somebody make a version of FPEmulator that pushed all the hard FP over to the PC card to be executed by the 486’s maths co-pro?

You might have to go with “possibly maybe”. :-)

That’s the same concept as using the GPU for computational purposes. I wouldn’t call it parallel because that seems to describe things of similar functionality working together. I’d call multithreading or multiprocessing concurrently on multiple cores parallel. Not really sure what I call co-processing beyond exactly that.

That makes me wonder. Let’s say a subsystem of RISC OS was offloaded to a supporting chip of a different architecture, for example the VideoCore GPU of a Pi. Would that be a licensing violation?

That makes me wonder. Let’s say a subsystem of RISC OS was offloaded to a supporting chip of a different architecture, for example the VideoCore GPU of a Pi. Would that be a licensing violation?

IIRC the Iyonix has an on-board version of the Intel NIC chip that is also available on a PCI card. Further to this if you install the PCI card version at least one version of the driver will work with the PCI card.

There exists open source code for the drivers for that PCI card which has it take much of the processing load of running the network connection. Port that and off load stuff from the Iyonix CPU. Have you breached the licence? I think not.
If you run a sub-system via a binary blob in a GPU (or other hardware) it does not violate the licence. Proof: Raspberry Pi video.

These things would just be a device you throw a request at and get a result.

Mind you, how soon you get to the borg situation is an interesting question.