Thinking ahead: Supporting multicore CPUs

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

+++++++++++++++++++ :)

Here’s mine… https://www.baxters.com/products/just-chicken-pie

@ Rick,

damn it, I still had no dinner yet! Ok, time to leave the keyboard and get some food… this thread is getting out of hand! :)

This thread has been quiet for a while. Here’s what a couple of years of experimentation and swearing has led me to:

RISC OS code is not amenable to being multi-threading, let alone multi-processing. But the good news is that that can be ignored a lot of the time.

A single, shared, SVC stack and set of handlers (etc.?) “legacy environment” will be available to one thread in one application at a time, determined by the Window Manager, or equivalent.

Other threads, of which any application may have many, can run independently of the owner of the legacy environment. They will either not use legacy SWIs, or sleep until the shared resources become available if they do use one.

I’d hope to make it possible to update a window while not in control of that environment, as long as windows aren’t being relocated at the time. (Eventually by modifying the Window Manager, initially by requesting and remembering all the rectangles visible for a window, without re-drawing.) That would allow video to be seamless, although seamless audio is more important.

I suggest that new module code should be service-oriented (my term, I’m sure it’s been done before and has a different name).

A flag in the module indicates that the SWIs it provides (up to 64 services, by name or number, like a traditional module) will not enable interrupts. It is, however, allowed to switch threads.

That means that each core may have a small svc stack available to those new modules; enough to allow them to block the caller thread and resume a service thread (running in usr mode) to provide the service, releasing the svc stack.

For example, all the system variable access and manipulation SWIs will be handled by a single thread (and GSInit/GSRead re-implemented as GSTrans and a buffer to read from), eliminating the possibility of confusion.

A pipe implementation that puts threads to sleep until sufficient data has arrived for them to be interested, or until there is sufficient space for them to put data into, allows for data transfer without blocking the system as a whole.

TaskSlots are mapped in and out of memory on each core as their threads are scheduled, and a service thread can use a client thread to perform actions in its slot’s memory. e.g. “copy that indirected icon text to here for me”.

So for RISC OS to survive WW3 (or its avoidance) is to let 26/32 and 32-bit RISC OS become history (but very well Emulated!) and rewrite the whole Operating System in C keeping the WIMP essentials intact.

Multi-Core and Multi-Threading in a Preemptive environment is sort of what it takes for a 2020’s Operating System to call itself “Modern” without fabricated exaggeration. The million or so UKP to achieve this are pipedreams, allegedly.

But I’d love to run my favorite RISC OS DTP/designer apps in such a system even using Emulation – creating content both for web and print. Just hope the PostScript printer driver support beyond four-color printing (old HexaChrome etc). It’d be fun getting into that again.

JUST BUY A PI!!!

I shouldn’t.

I really shouldn’t.

…

Dammit.

So for RISC OS to survive WW3

Trust me, mate, if WW3 kicks off, operating systems are liable to be the least of my concerns.

Any enemy worth its salt will target infrastructure. Which means no electricity, which means no prodding the keyboard.
Unless this goes nuclear, which means no electricity, no Pi, and quite possibly no Rick.

The million or so UKP to achieve this are pipedreams, allegedly.

FFS, don’t you think if anybody had that sort of cash to spend on RISC OS, things would be moving a little faster than they are right now?

There’s no “allegedly”. Go look at the bounties page. D’you see millions there? Are you willing to stump up that sort of money?

But I’d love to run my favorite RISC OS DTP/designer apps

You can. Right now. On multiple types of device. Just because the new Pi doesn’t support the 32 bit modes required by RISC OS doesn’t mean that:
a, everything else suddenly ceased working
and:
b, none of those devices are available any more

Is the 64 bit issue a road block? Absolutely not. At this stage it’s barely a speed hump.

You know, I am “lightly” interested in the Pi 400 because of the form factor. I’m not at all interested in the Pi 4. Because my main machines are a 3B+ and a 2B, and for what I do, both are fast enough and have enough memory.

Sure, maybe if I had RiscM and asked it to make a detailed map of northwest France I might want more, but I don’t, so I don’t.
And, anyway, “more” doesn’t necessarily mean a new machine. There are three entire ARM processing units inside both of my machines doing sweet Fanny Addams.

Pi 5? Technically it is interesting, especially that new chip they’ve produced. Would I buy one? Nope. Would I buy one if it could run RISC OS? Nope.

It’s a similar situation with mobile phones. I had to get a new one with contract renewal, so I got a “Redmi Note 12 Pro”. You know what my purchasing criteria came down to? It was cheap and it had an OLED screen which I felt would be nice for Netflix.

Cameras, stupidly high resolution for something so small. Plus multiple cameras, >FHD video, dual band WiFi, over a half dozen cores up in the 2GHz ranges, huge amounts of flash… what is it that differentiates one phone from another these days? They’re coming up with stuff like folding phones because mid range devices today are able to keep up with the flagships of just a few years ago.

Well, for me it’s much the same with the Pi. The two I have work fine for my uses. My complaints are to do with the underutilisation of the hardware and various architectural issues with RISC OS itself. A shinier faster machine will solve neither problem. A shinier better RISC OS…probably won’t run my applications, so swapping one problem for another.

creating content both for web and print

I already do that. It’s been quite a boon that Paint can now export PNG directly. I don’t need to use the PC to do that sort of thing any more. It would be nice if the export could cope with transparency, but patience, it’s Paint, there are other bugs that need fixing first. ;)

My blog is almost entirely written in Zap. Diagrams are made in DrawPlus, converted to sprite using InterGIF (annoyingly reducing to 256 colours but it decently anti-aliases the vector graphics), and Paint is used to crop and export as PNG. A lot of window shots also get exported from Paint. All of this is uploaded using NetSurf.

Paper? OvationPro, for those times when I’m not banging out a quick document with Google Docs…

It works. It works right now. It doesn’t need 64 bit, and while some discussion of 64 bit is necessary for future plans, all of the current stuff works. Making a 64 bit (remember – think x86-64 or you’re doing it wrong) version of RISC OS is not necessary to use the software that is already available.

Will the 64 bit issue be important? Of course, and with growing importance in the future.

Is it an issue right now?
No, not really. Just means that ROOL ought to add a note somewhere to clarify that the OS won’t run on a Pi 5. But the older ones, it will. And Pi isn’t the only game in town, just the cheapest. There are other machines quite capable. R-Comp even has a laptop. If I had more disposable cash (no, I don’t have a million in loose change between the cushions of the sofa ¹) one of those would likely be on my Yule list.

So, it’s not doom and gloom, and comparing the situation to a world war is asinine to the point of blatant trollery. Get a grip, would you?

¹ If I had a million to spend on something, sorry, I wouldn’t spend it on RISC OS. Or any OS. I’d like to provide better educational integration and support for local autistic children.

Doing graphics is both pretty RAM- and harddisk-intensive tasks, areas in which RISC OS is very limited still. Pretty sure this could be fixed for both 26/32 and pure 32-bt RISC OS systems, but the fact is that hasn’t supported the gfx/dtp market for RISC OS since it has has shrunk to the unsupportable as far as high resolution image handling is concerned. What I got away with (regarding RISC OS supported hardware) 30 years ago doesn’t count today – no surprises there.

That’s probably true for bit-image graphics; I wouldn’t know, I do that on the Mac. I used to use Photoshop Elements that I got free with a camera (somewhat limited compared to full Photoshop, but adequate for my purposes), but I use The GIMP now.

But for vector graphics RISCOS on a Pi is more than adequate. Everything I’ve tried on Macs or PCs is either less functional or less user-friendly than !Draw. That includes some bloody expensive things I used on PCs at work – but that was 16 years ago, and I may be a little out of date. I’m not going to look at expensive software.

Pardon, I should have specified bitmap graphics/(Sprites). Pure vector graphics isn’t an issue. For that I mostly used !ArtWorks (which I betatested for CC btw) and later, !Vantage a bit. !Draw is too limited for the jobs I did which demanded color graduations and/or transparencies to achieve the desired effects. Shadows..

!Draw is pretty good at colour gradations really. On old hardware you’d run into RAM size and speed issues quickly like that, but not on a Pi.

I manage to create and manipulate a 120 millions points (12000×10000 points, 16 millions colours) Sprite in Paint. It just works. Other software using dynamic areas could do much more I suppose, since the 512MB Wimspslot seems to be the limiting factor here. So I ask my question again: do you ever use a Pi4? Or even a Pi? You ask for things RISC OS can do today.

Multi-Core and Multi-Threading in a Preemptive environment is sort of what it takes for a 2020’s Operating System to call itself “Modern” without fabricated exaggeration. [snip] I’d love to run my favorite RISC OS DTP/designer apps in such a system even using Emulation.

Windows, macOS, HaikuOS or Linux seems to fit this need. Else, ROX can give you the WIMP+Filer experience on Linux. If you wan’t the RISC OS look on a modern stack, perhaps you could help the ROX project?

Else, perhaps you can give us clear and valid arguments on why the Linux kernel, Wayland, BBC Basic for SDL 2.0 and the ROX projects are not good enough and why we should code alternatives to them.

I manage to create and manipulate a 120 millions points (12000×10000 points, 16 millions colours) Sprite in Paint. It just works.

You don’t surprise me at all. I prefer the GIMP to !Paint because it’s so much more powerful than !Paint, but that !Paint can do its stuff on big sprites doesn’t surprise me. I used to use Photodesk at work when I ran the system at Physiology, but I don’t have my own copy of it and I’ve not used it on anything post-RiscPC. Do you know what it’s like on a Pi?

Doing graphics is both pretty RAM- and harddisk-intensive tasks, areas in which RISC OS is very limited still.

I don’t think the problem is necessarily the memory. Sure, 1GB might feel a little cramped (and anything less near unusable), but if you compare the likes of Google Photos, Snapseed, etc running on a middling Android device, it soon becomes clear that there is not only nothing even remotely close on RISC OS, but even if there was it simply wouldn’t measure up due to only having one core to run on. These days, I tweak and edit in near realtime photos that are 4480×2016 (as taken by my phone’s camera). Converted to a sprite, Paint can rotate it 1°ree; quite rapidly but SpriteExtend does a pretty lousy job. PhotoDesk did a better rotation (in about 7 seconds on a Pi 2); but these rotations are all guesswork as there’s no realtime preview, and there’s just not enough processing power to do that sort of thing.

Everything I’ve tried on Macs or PCs is either less functional or less user-friendly than !Draw.

I use DrawPlus. It’s like the Draw that Acorn should have made for RISC OS 3; and it’s close enough to Draw not to be a bit alien (like OpenVector or ArtWorks). One of the main things for me is how much easier it is to edit things, which is a little clumsy with Draw.

Having said that, yeah. I’ve only used free offerings (except some drawing package way back in the Win98 days, I forget the name) and while I’m sure that with a lot of time and effort I could have obtained reasonable results, the ones I tried were basically a dog’s dinner. Horrid clumsy UI.

Speaking of which… there’s not really any middle ground on RISC OS is there? If I want to tweak out a bit of red-eye, remove an annoying bit of fluff from a jacket, and crop (keeping aspect ratio)… well, Paint isn’t up to that and PhotoDesk is way overkill.
There’s also ImageMaMumbleMumbleDPScan which has a seriously quirky interface (page sizes!) and, well, I taskkilled it when my 1°ree; rotation had only made it to 4% in one minute. The results might have been lovely, but at that speed we’d be looking at a third of an hour per rotation!

I notice that CloverLeaf is no longer making any mention of ArtCube.

Speaking of Cloverleaf, the Patreon page has “Proposal 1: Printer driver” (porting a newer GutenPrint), saying:

The current RISC OS printer driver doesn’t support modern inkjet and low cost laser printers.

Oh yes it does!

Dave, you wanna take over here? ;)

Sendiri provide hardware graphics acceleration for the RISC OS 5 platforms, including JPEG rotation.

I got a GutenPrint9 with the latest ARMX6 package.

@Rick
On a PI4, a 1° rotation of a similar picture in DPlngScan takes 4 minutes and 40 seconds, which still is annoyingly slow, of course. The same rotation in Photodesk however is near instantaneous, and so it is in ArtWorks.

The current RISC OS printer driver doesn’t support modern inkjet and low cost laser printers.

Oh yes it does!

Well, yes and no. I’ve certainly written software that does it, and I know how to do more (choices of paper feeds, duplexing, etc.) but these are not in the current RISC OS printer drivers, i.e. it’s not quite in a condition to be generally released. Close, but no cigar…

Some of it is “just” handle-cranking. The bigger problem is the integration with Printer Manager.

The even bigger problem is Printer Manager itself. PM does not lend itself to being extended to transport via HTTP, nor to handling an extended set of choices. It’s written in BASIC, and it has grown in such a way and to such an extent that it represents a perfect example of a project that is too big for BASIC. It needs to be rewritten.

It leads me on to another subject: rewriting parts of RISC OS in C. I can see how to do that for code written in assembly language; I can imagine it being possible to move code over to C a chunk at a time; start at the top level and call existing code, and when that works, port another chunk, etc. But I cannot imagine any way to do that with a BASIC app; it would have to be done as a Big Bang. Nightmare.

If anyone would like to join in with the printing stuff, I would welcome help.

Do you know what it’s like on a Pi?

It’s much faster. Especially with a SATA drive. I just need to learn how to use it :)

Sure, 1GB

Nota: ongoing work will give us access to more than 4GB RAM. Cool for the 8GB Pi4.

Sendiri provide hardware graphics acceleration for the RISC OS 5 platforms, including JPEG rotation.

I hope Adrian’s work will restart soon. Here, Geminus was responsible of some hard locks when printing or using IRIS (especially on very big resolutions). Would be cool if solved. Would be even more cool with a dual head support on Pi.

I got a GutenPrint9 with the latest ARMX6 package.

Damned. Why all of this isn’t available on Store? (or via a generic subscription plan).

I’ve certainly written software that does it

Yup. And it works. It just needs a bit of massaging to get it to work with a thirty year old printer driver.

Close, but no cigar…

Ridiculously closer than before you started. Granted, it’s not a simple “click the print button” that the older drivers try to be, but on the other hand, a bit of faffing with another app is vastly better than “can’t do it”.
Plus you support both PWG (newer IPP Everywhere printers) and URF (older AirPrint devices), so as long as it actually supports either of those and isn’t something ancient that simply uses the IPP transport for it’s own data, it ought to work. Certainly I popped some alcohol free apple juice when I got something out of the HP inkjet.

The even bigger problem is Printer Manager itself.

Yes, I wonder how Stefan is planning on dealing with that? The thing with IPP is that it’s all very transient, due to being ad-hoc devices on a WiFi network. That’s why there’s all that mDNS stuff to deal with.

But I cannot imagine any way to do that with a BASIC app

A long time ago I saw a BASIC to C convertor. Never tried it so I don’t know what it outputs.

But I think the problem with this, as has been nicely demonstrated by previous code snippets, is that there are a number of things that C can do that would be missed by a blind overly literal translation. Structures, for instance. Extremely useful, but I think it would take a lot of smarts to make a sensible translation from BASIC’s blah%!offset% notation into structure elements. The alternative, I can imagine, would be an unholy mess using pointers.

it would have to be done as a Big Bang.

Nightmare, yes. But it would have the benefit of allowing one to completely revise the internal architecture to reflect modern times, rather than making a direct translation of the existing code and then attempting to patch in new features…to code that I can imagine would end up looking worse than the original BASIC (no, AI isn’t the answer to everything ;) ).

On a PI4, a 1° rotation of a similar picture in DPlngScan takes 4 minutes and 40 seconds, which still is annoyingly slow, of course.

And the Pi4 spec isn’t that unlike a lowish-end phone that can do it pretty much in real-time. Twice as many bits won’t speed things up (other than the architectural differences). Twice as many cores will. And four times as many cores? There’s a Yorkshire man sketch in there somewhere…

A long time ago I saw a BASIC to C convertor. Never tried it so I don’t know what it outputs.

Martin Carradus’s Mindleaf website.

On a PI4, a 1° rotation of a similar picture in DPlngScan takes 4 minutes and 40 seconds, which still is annoyingly slow, of course.

Am I going to say “Yay for FPE!” at this point? (sarcasm off)

Surely no-one really uses floating point for bit images?

Am I going to say “Yay for FPE!”

Yes, you just did.
At a closer look, Photodesk – that did the rotation instantaneously – largely exaggerated that 1°. I don’t have a carpenters eye, but I estimate the rotation at 15° minimum. ArtWorks however seems to do an excellent job, and instantaneously too. How would you explain that?