Thinking ahead: Supporting multicore CPUs

aaaaa

aaaaa

From what i could see, Library and application can also call the OS/Kernel part directly without going through wimp event system ?

Yes. You can call the kernel directly for for things that don’t directly apply to the UI. I inserted the Wimp in there to show its position relative to the application, libraries, and kernel.

Wimp OS/kernel -

The Wimp is above the kernel.

Wimp doesn’t seem to do hardware access does it ?

I don’t think so now, though I’ve not checked… Task swapping is now passed off to the kernel. It used to manipulate the tasks itself (RISC OS 3.5?) and it was rather slow at it – I’m not aware of the exact reasons but possibly because the Wimp was changing memory mapping outside of the kernel so had to keep the kernel aware of what was going on.

Mmm, you updated your post. Therefore, so have I.

is there a substantial difference between library and application level ?

RISC OS is not Linux. Both the library and the application are nominally the same level. It’s just that with a consistent library, it is easier to think of it as being a layer between the Wimp and the application. For example, DeskLib provides a nice event handling “framework” where you can associate event handling functions to specific events – for instance if the user clicks on my “main” window, DeskLib will manage that from the event dispatch until the point where it calls “main_clickhandler()” (or whatever I called it). It makes Wimp programming simpler.

library are run in user mode ?

CLib is part of the SharedCLibrary; but it jumps in using branch points so I suspect that for the most part it is USR/SVC agnostic. Other libraries? The parts that are required¹ tend to be linked into the executable.

wimp is not supposed to wrap or replace entirely the OS/kernel part to program application ?

How do you mean? The Wimp replaces a number of things that just don’t make sense in a multitasking world. For example, key presses are provided by Wimp_Poll events. An application cannot sit waiting on INKEY (like ReadC from stdin) any more. You can still draw to the screen, but under very specific cases (namely, redrawing your own windows). You don’t poll the mouse for position information, the Wimp tells you when something happens. And you don’t idle loop while waiting for something, you poll the wimp (which means, let other stuff have some play time with the processor).

No, the Wimp does not entirely replace the kernel, but it does make an important number of changes to the program environment and, dare I say, the paradigm² of how software is written.

¹ The librarian and linking system is quite nice. Libraries are often built out of hundreds of small pieces of source code all of which make their own object file; so when building an executable, the linker only needs to include those object files necessary to satisfy all of the references. Therefore, I don’t think there is one single program of mine that contains the entire 300-odd KiB of DeskLib.

² I can’t say that word without thinking of Dilbert.

The HAL ought to sit between the OS/kernel and the hardware, but it seems to me that a fair few things still talk directly to hardware. Not anything like as much as before, but some…

I can’t help wondering if a wider reaching 2-layer HAL would be useful.
Layer 1 is a set of small modules that talk down to the hardware and upward to layer 2, layer 2 talks down to layer 1 and up to the OS basically telling the OS a feature is turned ON if it exists and OFF if it does not.
Does the OS really care whether the disc storage is IDE, SCSI, SSD or even RAM?

I’ve lost track of which thread contained the pre-emption discussion… Anyway, take a look at this, it might be helpful: https://groups.google.com/forum/#!topic/comp.sources.acorn/Yql3tT-J0iY

aaaaa

aaaaa

aaaaa

aaaaa

aaaaa

They should not, but they are – by design – not compatible with PMT. So no choice.

aaaaa

aaaaa

aaaaa

FileSwitch ought to be reentrant. Think of how DOSFS and SparkFS work.

FileCore. There’s your fun scenario.

However… Excuse me for what might be a really dumb question, but what are you actually trying to do? You say preempted – but in what context? Wimp apps? Everything?

Or either need to check all the swi call that can be called safely from threads, and then either forbidding access to one that are not from preempted task.

You see, my (way simpler) proposal was to add a “preempted behaviour” to the existing Wimp. Sure, it is a far cry from what you understand and the preempted command line programs that you may be used to.
HOWEVER it is intended to work alongside the RISC OS way of doing things; not to try to bend RISC OS to become something it clearly isn’t. My proposal, and indeed Wimp2, worked on the principle that a program would be written with the knowledge of the pre-empted environment that was being entered in to. You will note that Wimp2 does not hijack and pre-empt existing tasks. It is actually somebody else that wrote the nifty code to munge normal programs into using Wimp2; and it works by having a list of programs that should never be preempted. This, I would imagine, was determined using the “suck it and see” method. I am worried that all this talk of where and when it is safe to preempt and potentially restricting access to SWIs… Most, if not all, RISC OS software was written in one of two modes. #1 it is a command line style program and will have exclusive use of the machine, or #2 it is a Wimp program and will run co-operatively with other tasks. It is possible to bend #1 slightly, for example the TaskWindow can run a build job with compiler and linker. Both are command line tasks. Both can be pre-empted within the Wimp environment. BOTH HAVE RESTRICTIONS – try loading the “!Depend” file that is temporarily created. You probably can’t, because part of the build process has it open. But this is considered “safe” as nothing else should be touching that file. It’s a compromise.

What you are talking of, however, is something that is a lot more involved than this. I’m worried about how much disruption it may cause existing tasks.

Fundamentally, RISC OS is a single user single process operating system with a clever task switcher built into it. Think of it like DOS with Windows 3. Okay, Windows could do a lot of stuff and was nifty, but it was still DOS kicking around underneath it all. Our setup is a similar sort of concept.

I am concerned that you think you are able to “forbid” access to certain SWIs. Why? Well…

• Upon which criteria would access to SWIs be permitted or forbidden? How do you plan to implement this for every possible SWI? Are the SWIs in my MIDI module “safe”? How do you tell?

• How do you plan to do this forbidding? If you return an error, a SWI that returns an error code means something went wrong. The application is allowed to abort. Or do you plan to hijack and modify the API? If so, be EXTREMELY careful here. RISC OS has extremely detailed API documentation and you run a risk of inadvertently breaking things. To give you an example, the OS_Mouse SWI returns the mouse position and button state in R0-R3. Wouldn’t it be nice to include information on the scroll wheel in R4? Well, you can’t. Because the API said R0-R3 are modified. So an application can call OS_Mouse on the assumption that R4 won’t be touched. If you subsequently touch it…

already does everyone agree that hardware access should be prevented from preemptive task ?

No. Hardware access should be forbidden from a user mode application period. Doesn’t matter if it is preempted, Wimp, or a five line BASIC program…

So if i understand correctly, it address the workspace area declared at the start of the module as starting at address 0 ? That’s something that has to do with the memory layout and virtual memory ?
Module have their private data stored as global variable starting at the base address 0 ?

Might I suggest before you plan to implement any form of pre-emption, you read the PRMs and understand how everything fits together. The books are laid out as:

• (books 1-4 date from the early ’90s)
• Book 1 – the kernel, modules, interrupts, video and VDU, character input/output
• Book 2 – filesystems
• Book 3 – The Wimp, and non-character output (ColourTrans, FontManager, Draw)
• Book 4 – “Other stuff”, sound and hardware and programming documentation, if I remember correctly.

• Book 5a – a set of updates to cover RISC OS 3.5 (dates from the late ’90s)

At least, you’ll need to read and understand pretty much the entirety of book 1 and the first half of book 3.

Then, you’ll know the answers to your questions…

it address the workspace area declared at the start of the module as starting at address 0 ?

…address zero is traditionally where the processor vectors are located. It is probably just initialising its array contents to zero (and may check this later with a simple is-it-non-zero test).

That’s something that has to do with the memory layout and virtual memory ?

What virtual memory?
[hint: RISC OS is not Linux ;-)]

Module have their private data stored as global variable starting at the base address 0 ?

If you read the chapter on modules in PRM book 1, you’ll know how and where modules store their private data.

aaaaa

aaaaa

aaaaa

aaaaa

Book 5a – a set of updates to cover RISC OS 3.5 (dates from the late ’90s)

Small correction – Volume 5 was for RISC OS 3.5 (1994), Volume 5a was for RISC OS 3.6 (1995).

aaaaa

It looks like you’re interpreting this rather differently to me. For me, I see the wimp PMT (and only in the wimp) as a means to task switch without having an explicit polling loop; maybe code which is ported, or something else where it is better to tell the system to “just interrupt me” instead of regular polling.
I also think that you are maybe turning this into a much larger issue because you are looking at it from a Unix-like viewpoint instead of a RISC OS viewpoint. Why? Because we have multiple tasks and those which could talk directly to hardware (any comms program before Hugo devised the blockdrivers; and some after via the blockdrivers!) and it wasn’t the end of the world. Obviously things would go wrong if two programs tried to do the same, but with care it was possible as anybody who used ArcBinkley (fidonet) and ARCbbs (bulletin board server) will know.

I see the wimp PMT (and only in the wimp)

Why? Because we have multiple tasks and those which could talk directly to hardware

Reference my comments about the HAL elsewhere, if the HAL is the only thing talking to hardware¹ and the OS talks to the HAL, any programs that want to talk direct to hardware could be fooled by the HAL into thinking they were talking direct. An application in one thread might think it has exclusive access.
Obviously the HAL would be a bigger affair, but then I think Jeffrey has tended to describe the existing HAL as enough to do the job rather than all singing and dancing.

¹ Layer 1 talks to hardware and layer 2, layer 2 provides the lie that a device that is just slow responding while in reality it is in use. Layer 2 should provide a platform independent view of the hardware to the OS so that the only difference between OMAP3, iMX6 and BCM2835 is the HAL. To the OS any missing hardware is reported as “turned OFF or not present”

aaaaa

aaaaa