Just something not so important

https://twitter.com/QtARM/status/1198181690700681216

At first I didn’t want to post it here, because of what I think is a bad climate when it comes to alternative ways to do things.

So.. comment if you like.

So.. comment if you like.Personally I dream of being able to let the other CPU decode mp4 or other heavy tasks. It is also a benefit that one can use 64 bit code when needed, without converting the whole RISC OS to it. I guess I need to write a little kernel!

Personally I dream of being able to let the other CPU decode mp4 or other heavy tasks.

Jaffasoft produced “ActiveApps” designed to pass messages between apps, and extension to this called “Gateway” would allow transmission to Applications on different systems by various means – on system, serial, Ethernet…
http://www.jaffasoft.co.uk/wwv2/activeapps/. Development was “paused” some years ago.

In the bottom of the page they reference and alternate:

Gateway was under-development, but has since been paused. If there is interest, it could be finished.
The implementation will be similar to the AATerm example shipped with WimpWorks.
Another alternative would be to look at reimplementing it on top of ØMQ.

0MQ is open source (on a quick skim there seems to be a mix of licence with the GPL taint in there)

Michael what a great piece of lateral thinking. Also great to see that you have ported RISC OS to the PineRock64 hopefully you will also be able to do the same for the PinebookPro. That would make a fantastic laptop.

Michael is this something that you will be making available to the RISC OS community?

At first I didn’t want to post it here, because of what I think is a bad climate when it comes to alternative ways to do things.

People don’t always agree on the same way forwards. Or the timescales. Or how to do it. Or in which order. I guess it’s natural, and possibly a side effect/consequence of a small developer community (meaning things need to be prioritised, there’s no “RISC OS 7 by Q2 2020” with a team of devs).

Don’t worry too much about the climate (cold, miserable, apparently an “emergency” according to a young Swedish girl that terrifies middle aged men) and go ahead with your plans. Good ideas will see themselves taken and accepted, lesser ideas will fall by the wayside. It’s just how it goes.

So.. comment if you like.

That’s sort of what I was thinking way back when.

RISC OS would run on one core, and any other cores would run their own code with a tiny kernel and some sort of interaction between them and the RISC OS host. Think of it as a “sort of like the Tube”.

Would it be capable of running 32 bit code on other cores, or is it only intended to be 64 bit? I’m afraid I find 64 bit ARM to be… very un-ARM-like.

How will your plan arbitrate if there are multiple clients wanting to make use of other cores? At the moment you appear to be running a simple single task; however when your development meets the wider world (especially if it can cater for 32 bit code) then there could be a number of possibilities here. I’m sure we all have a list of things that we do/use that hog the machine for a few moments. Any number of them could theoretically stall only themselves (and not everything) while another core does the work. It might also bring up the ability to have work be done in the background without unduly affecting the host.

The thing is, RISC OS is going to be stuck running on one core for the forseeable future due to the number of reentrancy issues and the prevalence of turning off interrupts while doing “complicated” things. Not to mention how the entire Printer subsystem works. This isn’t a specific criticism of RISC OS, just an observation that it was clearly born in a different era, an era where multi-core processors was about as unthinkable as was the idea of an ARM clocking a thousand megahertz (only 125× faster than the hardware of the day).

So, yes, it makes sense to utilise the additional core(s) to shove off some heavy crunching to just “get on with it” while the main core runs the OS.
Though… I’m not so certain about mp4 decoding… shouldn’t that be tossed to the GPU to do? ;-)

At any rate, well done!

I’d attach a “beer glass” icon, but Google seems to think that 1000×1080 is an “icon”, and the smaller ones are either monochrome or look like badly failed mug cakes.
So… click this link and enjoy a suitably large beer (too big to insert into the forum). :-)

That’s sort of what I was thinking way back when.

RISC OS would run on one core, and any other cores would run their own code with a tiny kernel and some sort of interaction between them and the RISC OS host. Think of it as a “sort of like the Tube”.

Yup, hence me mentioning the ActiveApps/Gateway stuff and 0MQ…

I’d attach a “beer glass” icon, but Google seems to think that 1000×1080 is an “icon”, and the smaller ones are either monochrome or look like badly failed mug cakes.

I’d point at something from my summer “holiday” but the CAMRA GBBF publicity team and the web maintainer seem to think 2.6MB is a perfectly normal image size PNG https://s3-eu-west-1.amazonaws.com/www1-camra/app/uploads/2019/08/19141537/EB37QvAXoAAVgv_.png (I’m actually about 3 metres in front of the camera taking the shot. Having the black backdrop in between the camera¹ and me is quite deliberate. :)

¹ Funny how muscle memory works. I typed the word camera as camra several times before getting it right (for this context)

alternative ways to do things

Acorn was always about alternative ways to do things. And I for one will die on this hill.

However, I would strongly recommend that you think about multiprocessing in a platform- and CPU- agnostic way. There is no point producing something that only works on this processor or that board. We should have learned from the 26bit/32bit hurdle that being processor-specific is short-term thinking.

I would advocate for a portable API such as OpenCL. ARM have made their OpenCL implementation available here (not that I’ve even downloaded it never mind built it – I don’t use an ARM processor here).

In a perfect world, an OpenCL API would allow a multicore ARM to build 32bit or 64bit code as appropriate, whilst an emulator on Windows (for example) could build x86, AMD or Nvidia code, and the RISC OS host program would benefit from a powerful computation engine without being bound to whatever processor a generous developer such as yourself happens to own.

I’m also intrigued by the possibility of supporting WebAssembly which, though it is not in itself a parallelising technology, is definitely a platform-agnostic one.

And I for one will die on this hill.

Certainly. If we weren’t “alternative”, we wouldn’t be here.

In a perfect world, an OpenCL API would allow a multicore ARM to build 32bit or 64bit code as appropriate,

That sounds suspiciously like you are starting from something that is not pure code, and are simply translating/building it for the processor prior to execution (like Android apps, Java, etc).
We simply don’t have those sorts of technologies.

I would suggest that “supporting ARM” is sufficient, as RISC OS itself is heavily tied to the ARM and we should be looking at potential solutions possible today, not great solutions at some future date.

However… there are multiple multi-core devices that RISC OS exists upon these days, the API should support them all, even if exact implementations must differ depending upon the hardware (akin to video support in RISC OS).

I would suggest that “supporting ARM” is sufficient, as RISC OS itself is heavily tied to the ARM

ARM OpenCL is part of the ARM-ComputeLibrary – “a set of functions optimised for both ARM CPUs and GPUs using SIMD technologies”

Sounds awfully like a library of code to support single and multi-core ARM devices to me.

It might be possible to have both cpu in 32bit mode, and that might be good before we have working aarch64 compiler that runs on riscos.

But I think we could benefit of having 64bit mode as well.

we could benefit of having 64bit mode as well.

Certainly. I never discounted that, I only asked that it support 32 bit as well (since your example is 64 bit).

I need to get USB working again before I can do something more integrated.
It stopped working after switch to A72 (for riscos).

The more I think of it, the more attractive wasm is.

• Genuinely processor agnostic
• High performance
• Huge choice of source languages
• massive support from big players
• still new enough to not be bedevilled by multiple revisions and special cases
• “so hot right now”

I’m playing with it and I like it.

Note that the compiler (though that’s the official term it’s the wrong word really – it should be “transcoder”) could build and run ARM32 or ARM64 depending on your ‘other’ processors; on a single core it could be run in the background; on an emulator it could be pushed out to the host OS and run as x86 or GPU code. Exciting.

USB is up again! So the fun can now continue! ( was interrupt related )

The more I think of it, the more attractive wasm is.

Not looked at it in detail, but I guess you have…what is the advantage compared to e.g. Java bytecode or LLVM Bitcode? Apart from “can be executed directly in the browser” of course.

Apart from “can be executed directly in the browser” of course.

That’s not an advantage from where I stand.
Just yet another thing to have to find a way of blocking.

what is the advantage compared to e.g. Java bytecode or LLVM Bitcode?

Versus Java, it’s faster, more secure and much, much smaller. And a significant advantage is that there isn’t an implicit humungous standard library (4,500 classes in Java now?!).

As for LLVM, wasm is totally portable – the same binary runs on any platform. That isn’t true of LLVM’s intermediate representation. However, LLVM IR can apparently be converted to wasm.

Regardless, I think there are significant advantages to adopting an international standard over something that only works on this Broadcom chip or that particular ARM board. A ‘multicore’ system that could work inside an emulator without having to emulate additional cores is also very attractive.

That’s not an advantage from where I stand.

On the one hand, wasm runs in a sandbox so cannot mess with your system (in fact the only thing it can link with is a set of functions that you have supplied) but having said that, it turns out that the majority of uses of wasm found out there in the wild west of the internet are actually illicit bitcoin miners. Ahem. That has no relevance to this application though (probably).

My 5c, not that it may count for a lot around here:

This is an excellent starting point for dealing with heterogeneous CPUs, and no matter what people may think about using intermediate bytecodes and ILs, you still need a way to bootstrap and manage those additional cores, and right now, RISCOS has no real infrastructure for doing so.

From what I’ve seen of the OS in my little journey towards a new IP stack, it’s far from trivial to address without this sort of approach to side-step it.

Architecture independent ILs (wasm is an IL, even if they call it an executable – it still needs translation or interpretation to do anything – I can’t just point the CPU’s PC at a wasm bytestream and have it work) are simply another layer you put on top of this sort of foundation.

What probably makes WASM a bit unique here is that it probably has a machine spec that goes with it which the system is assumed to provide or emulate, making it less OS/target specific. This is not really a benefit to a lightweight/simple operating system. IL translation and virtual machine/sandbox implementations add bulk and hidden security risks, and one that performs well is not a trivial matter to write.

The key thing is – TANSTAAFL – you still need to support the metal, irrespective of what you translate to run on it. This sort of effort really makes sense to me given the current state of affairs, with the benefit that, done right, it can be emulated fairly trivially in an more conventional preemptive-multitasking system later should that become the final evolutionary path.

you still need a way to bootstrap and manage those additional cores, and right now, RISCOS has no real infrastructure for doing so.

Partly incorrect. Jeffrey provided API and code to access other cores on the Pi.
https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Programmer/SMP/

We now need people that would use it and extend it (light threads in C?)

Following up on David’s post, there are actually release (well, beta release) ROMs for ARMX6 with SMP capability, and have been for about 2 years now. I wouldn’t like to say which came first (pi or i.mx6) but I suspect Jeffrey was working on both in parallel, which would be kinda appropriate for parallel processing ;) AFAIK this is an on-going thing, as many SWIs/APIs in RISC OS aren’t thread safe, so need to be made so over time. As a result, using the SMP build of RISC OS as a general purpose one isn’t very practical for software compatibility reasons. Or at least, didn’t seem so at the time.

However, this from Michael is a little different, as it isn’t RISC OS with SMP, but rather a way of having the other cores operate independently of RISC OS, executing code whilst RISC OS runs “normally” on a single core. In this mode, I wouldn’t expect software compatibility issues with existing software, but obviously code running on additional cores would need to be quite specialised. I’m just intrigued where it might lead….!

https://twitter.com/QtARM/status/1199286348068327427

Sprite live updated from the other CPU. I simply map the framebuffer from the A53 and sets it as buffer for the sprite. I hope to code a more animated example soon :D

But this is a important step for the project.

Michael’s work is very welcome, as was Jeffrey’s. But to use Michael’s example, it is not reasonable to expect application authors to build an aarch64 ‘worker’ on the off-chance that the program happens to be running on silicon with such a core available. Where another core is ‘only’ aarch32 that would be another build. One might also need a 26b build for legacy/emulated systems. It would be very easy to slip into the “well it works on my machine” trap.

Mark my words: Whatever silicon capabilities you build requirements on now will have to be emulated in the future.

I’m suggesting an alternative approach that removes the dependence on any particular hardware. I’ve long advocated for a ‘web worker’ model for multiprocessor utilisation, and that’s from experience of using a thread-pool system to parallelise a massive single-threaded product (of over 2000 source files).

“Other virtual machines are available” of course, but I don’t think there’s any point in airing personal theories about ‘security risks’ and implicitly claiming one knows better than Mozilla, Microsoft, Google, the W3C and Brendon Eich. WebAssembly has a lot to recommend it.

A wasm interpreter is easy to build. A good, optimising code generator (i.e. “compiler”) for a particular arch is less so, but I’d argue that multiprocessing that works everywhere is better than MP that works really fast on this board and not at all on anything else.

many SWIs/APIs in RISC OS aren’t thread safe, so need to be made so over time

That just ain’t going to happen. You will have the RISC OS thread and then worker threads that have a massively reduced API, which will not be RISC OS. You need to picture exactly how many hooks, events, vector calls, service calls, callbacks and other amazing stuff get called by the RISC OS API. It simply does not parallelise.

is not reasonable to expect application authors to build an aarch64 ‘worker’ on the off-chance that the program happens to be running on silicon with such a core available.

Well yes and no. aarch64 is here now, and I think aarch128 isn’t around the corner. It would be quite easy to run both ( or more) in 32bit. I am sketching on a upload system from riscos, with some simple commands that can make the other cpu/core decide if run code or not.

But,

This is just I start , and I don’t know how it will progress.

Well yes and no. aarch64 is here now

No it isn’t. Not on my machine. Do you see?

It would be quite easy to run both [aarch64 & aarch128] (or more) in 32bit.

What?! You must mean by emulation? In which case I think you’ve just proved my point for me.

I don’t know how it will progress.

Keep going, it’s important work. But do read up about wasm if you find time.

Where another core is ‘only’ aarch32 that would be another build. One might also need a 26b build for legacy/emulated systems.

It’s common practice to compile or write RISC OS software so that it runs on everything from ARM2 to ARMv8. Also running AArch64 code is a separate issue, only the addition of an AArch64 HVC handler to run the code, and an AArch64 interrupt handler stub to direct interrupts to the RISC OS interrupt handler is required. Use of the long page descriptors is helpful to allow page tables to be shared between AArch32 and AArch64.

Pre-emptive multitasking and multi-core are similar problems, but there are many ways to be single core thread-safe but be multi-core thread safe.

One approach to allow calls to many RISC OS APIs is if a SWI that is not marked as thread safe is called in an extra thread, interrupt the legacy thread at a suitable point (during Wimp_Poll, in a callback, or when interrupts are enabled) and call the SWI. This would produce an environment that is mostly compatible Taskwindows, except for the case where user mode code in a Taskwindow shares memory with non-premptive code in another thread, callback context, or interrupts.

Concurrency can be improved by giving a thread it’s own instances of a carefully chosen set of modules. The extreme case is to run a RISC OS instance per thread, which I use in parallel srcbuild.