I give up!

(replying to a couple of general comments)

You may believe there are other architectures in existence, but I couldn’t possibly comment…

You missed the RISC OS Pyromaniac FontManager. Which doesn’t use a FontCache in the system at all, or implement any Acorn font formats. And is implemented in Python. So it is the most different from any of the others. Although certainly not what Simon was discussing… but it is an entirely different architecture.

*help fontmanager                                                                                                                                                       
==> Help on keyword 'FontManager' (Module)                                                                                                                              
Module is: FontManager     0.02 (06 Sep 2021)                                                                                                                           
                                                                                                                                                                        
Commands provided:                                                                                                                                                      
  FontCat         FontList                                                                                                                                              
*fx0                                                                                                                                                                    
                                                                                                                                                                        
Error: RISC OS 7.58 (14 Apr 2024) [Pyromaniac 0.58.4574 on Linux/x86_64] (Error number &f7)                                                                             
*                                                                                                                                                                       

As for the reasons for removing the Kernel collusion in FontManager… As always, this was to aid in the modularity of the system. In this case, that means:

• Removing the need for the Kernel to support higher-level modules – focusing on Kernel-only tasks.
• Removing the need for the FontManager to know about the Kernel.
• Removing the ‘for internal use only’ restriction that makes it hard for non-‘internal’ users to work with the system.
• Removing the need for the developer to be able to reason purely about the FontManager they are implementing.
• Making it possible for other developers to produce replacement modules without having to worry about how the Kernel will get in your way.
• Simplifying the distribution of module upgrades by removing the dependency of the FontManager on the specific implementation in the Kernel.

This has the effect of making it easier to develop:

• You don’t need to distribute an entire ROM because the Kernel and FontManager collude.
• You don’t have to consider the implications of changing the Kernel on the internal implementation of the FontManager
• And vice-versa.
• Loading a new FontManager is safer.
• Testing the FontManager only means that the FontManager is needed.
• The amount of extraneous code in the already-over-complex Kernel is reduced.
• Making the process of moving to different structures of systems (eg a new FontManager architecture, or even new CPU architecture) becomes simpler because the problem is isolated to one module.

And for me:

• It hurt my head less by not having to deal with all these issues whilst trying to handle developing the OS.
• It hurt my sense of sanity less, by removing legacy hacks that should have been removed years ago.
• I really wanted to remove the blockers which make it harder to work with the operating system.
• It means there’s less you have to apologise to others for when they have to deal with this sort of thing (like “why does the Kernel have this call into the middle of the Font Manager?” “Oh, it’s because 10 years ago, Acorn didn’t have dynamic areas so they called into a quick and dirty interface in the FontManager to let it know that the system changed, then they exposed the dynamic area interface that was previously internal and never bothered to update the FontManager to be aware of this properly. And this situation persisted and you’re still having to pay that price”)
• Listening to contemporary arguments about how hard it was to disentangle a component from the system (specifically the Microsoft Windows/Internet Explorer entanglement, but others at that time as well) indicated not only that collusion in that form was bad technically, but it had a negative impact on public perception. RISC OS can’t be doing bad things that others do, are clearly viewed badly, and are technically bad. We have to strive to improve things.

These things were important to me.

Hear hear.

4.3 was quite a big change.

Is there any way of incorporating these improvements into RISCOS 5?

i think the answer to that question is to ask **** nicely & say pretty please.

Listening to contemporary arguments about how hard it was to disentangle a component from the system (specifically the Microsoft Windows/Internet Explorer entanglement, but others at that time as well) indicated not only that collusion in that form was bad technically, but it had a negative impact on public perception.

Some people learn from history, others are doomed to repeat it.

Copilot.

i think the answer to that question is to ask **** nicely & say pretty please.

I think it might take a little more than just asking nicely, but one can hope.

Is there any way of incorporating these improvements into RISCOS 5?

I think the next push should be to making modules run in usr32 mode, then under a 64-bit kernel.

The Wimp is one of the more complicated modules to modify and, so far, the changes are about 1300 lines of assembler.

run in usr32 mode

Using whose stack?

Using whose stack?

The one for the module’s task.

Not the clients’, obviously; you can’t even assume there is one.

• Client calls SWI
• Kernel blocks the client task, puts it into a queue for the module task
• Module task takes the SWI from the queue, performs the action in the contect of the client, updates the client’s registers and resumes the client task

Rinse and repeat.

It gets a little more complicated than that if the SWIs recurse back into the same module, like the Wimp’s certainly do and file systems probably will.

Then you need at least two tasks, one to monitor the queue, the other to perform the actions.

There’s not really that much that modules do that needs to be done in a privileged mode, especially not if they’re provided with local user mode access to device memory mapped I/O.

I presume “the module task” here means “the usermode Wimp-equivalent”.

Bear in mind that the parameters for the SWI are intended to be valid in a privileged mode, so can refer to memory that isn’t accessible in user mode – those SWIs (like Wimp_TransferBlock) obviously need to work as normal.

There’s not really that much that modules do that needs to be done in a privileged mode

If you maintain the current Dynamic Area protections then modules like FontManager, SysLog, RamFS, WindowManager and even LineEditor will need to run in a privileged mode. Or you have to lose all memory protection.

I presume “the module task” here means “the usermode Wimp-equivalent”.

No, I mean a task tasked with running the module’s code. Either by modifying the module source code to be aware of the multi-processing features, or, possibly, providing a wrapper that can intercept SWIs and call the module’s code. Perhaps that will require some support code to make up for any assumptions of priviledge.

The Wimp is still a module, but it won’t manage memory any more. As tasks make Wimp calls, they’re blocked waiting to be re-entered when the Wimp determines they should become active. When StartTask is called, it Spawns a new task in a new Slot, and runs the command in that.

If you maintain the current Dynamic Area protections then modules like FontManager, SysLog, RamFS, WindowManager and even LineEditor will need to run in a privileged mode. Or you have to lose all memory protection.

I suppose so, or you change the memory protection.

I wonder, in the font modules you have, do they understand the format of the font cache? Do they access it directly, or do they make requests of the FontManager? Are they all compatible with RO 5, which doesn’t seem to use FontV (maybe I’ve missed something)?

A quick precis of where I am:

I’ve written a kernel with a fairly small set of features, in about 6000 lines of code, mostly C.

• Tasks (and TaskSlots), with locks and mechanisms for tasks interact at low levels (includes interrupt tasks, multi-tasking and multi-processing)
• Pipes (for passing data between tasks and some memory sharing)
• Queues (for managing tasks calling SWIs)

None of that is RISC OS specific.

There is a module subsystem that knows the format of a module and will find and run the SWIs or commands they provide on request. (Still not entirely RISC OS.)

The legacy part of it is the most frustrating, to say the least: trying to let existing RISC OS code to continue to run. Essentially, that’s come down to a service task that maintains a single legacy SVC stack and allows one task at a time to run a legacy SWI (so, behaves like today’s RO), except when it returns to usr mode, another task gets a look-in.

I wonder, in the font modules you have, do they understand the format of the font cache? Do they access it directly, or do they make requests of the FontManager? Are they all compatible with RO 5, which doesn’t seem to use FontV (maybe I’ve missed something)?

What I have is a prototype (and may well be a “Plan to throw one away, because you will”), but it’s the only FontManager that actually does use FontV, which is used as the spine from which the rest of the modular FM is hung. Crucially, it’s a prioritised vector (without requiring VectorExtend) so functionality is defined to occur at particular levels (or layers).

The FontManager module provides three of those layers: The SWI front end (and compatibility code for the Arthur SWIs – they never appear on FontV); the layout layer in the middle; and the cache implementation at the very lowest level. Other modules (typically font format backends) can therefore cache font-related data without knowledge of the implementation. FM4 implements its own DA, removing the Kernel DA if there is one.

I’m confident that architecture will persist, though implementation details are subject to my continuing unease with the impact of text shaping on the FM API, and the complexity of incorporating OpenType’s Feature, Script and Axis repertoire into the RISC OS model.

Essentially, that’s come down to a service task that maintains a single legacy SVC stack

There’s no essential reason why there should be only one SVC stack, other than the Wimp’s horrific stack-punning where it exits to a new task using the same stack with which a different task called it – this is a serious flaw which TaskWindow has to work around by copying its own SVC stack when preempting its child and restoring when returned to.

The Wimp probably should do that, and for the sake of a bit of memory each task could get its own SVC stack. I haven’t thought about that long enough to decide whether it’s sensible. AMBControl would have to be upgraded to allow non-contiguous blocks (at the mo it’s all app-slot) which would allow the long-planned-but-never-implemented task-linked DAs to be done (which could therefore be overlapped, assuaging some people’s misgivings about address space greed).

Oh the TaskWindow will be the first against the wall…

Tasks will take input from and send output to pipes, which may or may not be attached to files, serial ports, network connections, or, in rare cases, the VDU subsystem (which will probably be the only place to use WrchV). It might be fun to detect if the first characters are a mode change and provide a window to fake the graphics environment.

A new TaskWindow implementation then becomes a text display window that captures and displays output and passes keypresses caught by the window to the program being run.

Did you see my post about API modules? https://www.riscosopen.org/forum/forums/2/topics/19462

Oh, and I definitely tried an SVC stack per core, probably lots of little SVC stacks, etc., but none of it worked with the existing code without risking locking up. The biggest problem is having SVC code be interruptable and the interrupt code being allowed to make SWI calls, CallBacks, Service Calls, etc.. Nightmare.

Hence, an underlying kernel whose task it is to make programming easy and a subsystem whose task it is to keep legacy code happy (or at least working).

Still a work in progress, of course.

There’s a FontV? Edit: never mind!

I think a few of the lesser documented vectors (like FontV and DrawV) may have been added with the aim of helping the printer driver poke it’s tentacles into everything work it’s magic.

Perversely, because FM has not previously used FontV, it has to monitor the Service_Print service call and call into the Printer Driver via a dedicated SWI if there’s printing going on.