Suggestion: API modules

Regarding CallASWI; I thought of that, but then realised that it has a specific SWI number, and is actually part of the ‘original’ SWI system (the one we are still using), and thought it could get confusing to recycle that for a new usage all these decades later. CallASWI is tied to the current ‘SWI-number-in-instruction’ system, whereas I was thinking more of a new way to call SWIs without needing to read the instruction into the data cache (which still happens with CallASWI)

Problem is, SWI 0 already exists, and it is used → OS_WriteC. So while your idea is logical (and, I believe, similar to how Linux uses SWI on ARM hardware), it is incompatible with current RISC OS, thus making transitioning (even) harder.

Perhaps a middle ground could be to use CallASWI, and then (in 64 bit only), define CallASWI to be SWI 0 and require the number to be passed in a register?

SWI -1? :)

CallASWI may actually be a good idea – if we are going to go platform agnostic, then having everything linked into a single SWI would make it easier to use macros / etc to remap syscall type features on any CPU architecture to map to (an updated CallASWI)

Any SWI system on a 64 bit RISC OS is going to have a completely different calling mechanism at the assembler level, but as it’s a completely different assembly language there is no need to try to retain any compatibly with the existing mechanism.

What will need to be done is a translation layer between old and new SWI systems. In BBC BASIC programs this can be done by the SYS keyword, C and other higher level languages will have to be relinked against a new library which implements the translation.

“Any SWI system on a 64 bit RISC OS is going to have a completely different calling mechanism at the assembler level, but as it’s a completely different assembly language there is no need to try to retain any compatibly with the existing mechanism.”

Agreed; this is one reason for looking at ‘SWI without the number encoded in the instruction’; if we move to different platforms like ARM64, or even more different platforms like RISC-V or x86-64, then relying upon a single instruction in the design of RISC OS 64 for the ‘SWI’ interface will be a good thing

relying upon a single instruction

Ignoring the other instructions required to compose the syscall/SWI number ;-)

Follow the SWI instruction by the SWI number to be called. This is not unlike the current mechanism, which has to read the full instruction (pointed to be R14-4) to get the SWI number as data. It doesn’t require the SWI number to be passed in a register.

For those who haven’t watched Gerph’s 64-bit presentation, his suggestion – as I understood it – is to put the SWI number in R10 (known as x10 on a 64-bit machine) and then call SVC 0.

.bq “ Ignoring the other instructions required to compose the syscall/SWI number ;-)”

I thought about that – however – there will be cases where it isn’t obvious; an example could be a program that wants to preserve flags (excluding overflow) across a SWI call. If wanting to shrink code size (and thus cache usage, depending on the purpose of the code), it could have a subroutine

DOSWI1
STMFD R13!,{R14}
MRS R14,cpsr_f
SWI 0
BIC R14,R14,,#1<<28
ORRVS R14,R14,#1<<28
MSR cpsr_f,R14
LDMFD R13!,{PC}

If code used this subroutine for SWI calls, it would not be immediately apparent what the code did (at least in disassembly)

a program that wants to preserve flags (excluding overflow) across a SWI call

That’s 26 bit behaviour. The idea of preserving flags across SWI calls was ditched in 32 bit. Stuff just doesn’t expect that to happen any more.
https://web.archive.org/web/20080214124042/http://www.iyonix.com:80/32bit/32bitTech.shtml

it would not be immediately apparent what the code did (at least in disassembly)

Stash R14 (return address) on the stack.
Load current flags into R14 from CPSR.
Call SWI &0.
Clear the V bit.
Set V if V set (on exit from SWI).
Push R14 (flags) back to the CPSR.
Reload return address from stack directly into PC to exit.

Seems clear enough to me. ;) Just… I’d not be writing my code with clever tricks that assume the flags span SWI calls (which was always a bit dodgy given that lots of things mess with the C flag).

We’ve really got to get away from thinking at the assembler level, registers and flags, and switch to thinking at the functional level.

RISC OS modules provide commands and up to 64 functions that can be called from programs.

The functions can take multiple¹ input parameters and return multiple output values or an error² (which makes them different from functions in most programming languages).

Traditionally, the functions operate on a single module (or the preferred instantiation³).

The APIModules idea allows the functions to be associated with objects managed by a module (and multiple modules providing the same functions).⁴

¹ Up to 10?

² Editied to add error return

³ preferred instantiation, along with current filing system are abominations that affect every program running. In a multi-tasking environment, that’s a really Bad Thing.

⁴ _{Will object orientation ever really catch on?}

current filing system

It’s a BBC Micro.

Don’t I know it!

My umpteeth approach to making it work in multi-processing system is to have one special SVC stack that’s owned by one task at a time while it executes any legacy SWI. Everything else that doesn’t call a legacy SWI can get on and do its thing.

We’ve really got to get away from thinking at the assembler level

Yes. The previous assembler wrapper is a good example, because it won’t look anything like that in 64 bit and, really, remind me again why – in 2024 – we’re using assembler for anything more than “because I can”?

Up to 10?

Looks like both BASIC and _kernel_swi() permits R0-R9 to be used.
But, remember, it’s possible to pass in and out much larger amounts of information by passing a pointer to a block. That’s not so different to passing pointers in, say, C.

along with current filing system are abominations that affect every program running

Not so much. In combination with FileSwitch and paths, these issues really only affect command line programs and lazy programmers that make too many assumptions. But it is, as Stuart points out, a factor of the single-process single-context behaviour of the OS in general.
That’s another part of why I think if we’re supposed to make a breaking change to ARM64, then it might be worth looking at fixing up some of the underlying issues rather than trying to duplicate exactly what the OS is right now.

Unless, of course, anybody here thinks that preserving the API that has been us through since when I was at school all those many years ago is preferable to such things as pre-emption and using multiple concurrent cores?
Oh, and we’d probably need to replace the SWI mechanism with something that isn’t going to run into problems on less capable processors than the ARM.

less capable processors than the ARM

I don’t think that will be a problem; even Intel has “In 64-bit mode, sixteen general-purpose registers available”.

https://cdrdv2.intel.com/v1/dl/getContent/671200

Unless, of course, anybody here thinks that preserving the API that has been us through since when I was at school all those many years ago is preferable to such things as pre-emption and using multiple concurrent cores?

That would be me. As the old saying goes “If I were going there, I wouldn’t start from here”

It’s possible to both preserve the old API and to utilise such things as pre-emption and using multiple concurrent cores in new programs.

Honest!

Wimp_SendMessage → UserMessageRecorded.

Not to mention a potential for a lot of time wasting fiddles in order that a task could be swapped out during a redraw loop.

Oh, and you’re on your own with printing. There’s a reason it single tasks.

Yes, and like I said up there:

My umpteeth approach to making it work in multi-processing system is to have one special SVC stack that’s owned by one task at a time while it executes any legacy SWI.

That includes Wimp SWIs, but they only block the main task in a program, new programs can be merrily doing their own thing on all the cores. I also expect that secondary tasks could be allowed to do Wimp_UpdateWindow/Wimp_GetRectangle loops while the main task is polling.

Oh, and you’re on your own with printing. There’s a reason it single tasks.

Cos it’s processor intensive and needs to be offloaded?

but they only block the main task in a program

You forget the font/VDU/ColourTrans contexts. These might be able to be saved around task switches, but it’ll be a bit ewww to have to do.

Cos it’s processor intensive

I draw your attention this ickiness.

No, because anything using those mechanisms will be running under the Wimp, thus cooperatively tasking. OS_WriteC style output will become the exception, rather than the norm, precisely because it does affect the whole system. Most programs will output to a pipe. Legacy programs that need it are probably too old to cope with 4k displays, and can have a VDU code interpreter sitting on the other end of the pipe. The names Druck and GraphTask ring a bell.

I’m sure the font module code can be modified to maintain two contexts: one for the fonts loaded, and the other for a particular client’s choices. Draw only needs the latter. The system can simply claim an instance to implement the original SWIs.

An ARM64 example (it is actually quite similar!)

DOSVC1
STR X14,[X13,#-8]! // STMFD R13!,{R14}
MRS X14,nzcv
SVC 0
BIC R14,R14,#1<<28
ORRVS R14,R14,#1<<28
MSR nzcv,R14
LDR X14,[X13],#8
RET X30

of course, this is using X13 rather than SP…

I don’t think any new code for the kernel should be in assembly (with the exception of the very low level code that has to be, such as the parts of the memory management code that directly alter system registers). I also think that RISC OS 64 should be written in C, not assembler.

All that said, the reason I discussed assembler is because it is, in some ways, intricately tied to some aspects of RISC OS. One example is BASIC; it has a built in assembler. I am hopeful that, in RISC OS 64, there will still be a way to call system calls from assembler, so that this can be done from BASIC assembled code. While we should remove assembly from RISC OS itself, assembly will still also be helpful in BASIC code, for optimising small parts of it (so, this is one example of how assembly still has some uses).

Looking at the BBC BASIC reference manual, the ‘SYS’ command in BASIC … also returns the processor flags to a variable! So this is another reason flags still have some role – they are built into the API, at least in BASIC (it would be trivial to ‘set the error bit’ when returning from a SYS call in BASIC if the kernel returns ‘an error’, of course).

.bq “Oh, and we’d probably need to replace the SWI mechanism with something that isn’t going to run into problems on less capable processors than the ARM.”

One way to make it more flexible could be to have a ‘bit’ in the SWI number, as we do now with the ‘X’ bit, which is set if we pass a parameter block, rather than registers; ‘R1’ could then be a pointer to such a parameter block, which itself is just R1,R2 … etc in sequence, and which could also be used for returning modified registers. That would allow multi-register SWI use on CPUs that support it, or parameter blocks on CPUs that don’t;

While this is, of course, going back to ‘the CPU’ level, there will always need to be a low level ‘SYSCALL’ – the other OSes do this too – Linux SVC #0.

In higher level languages, these options could be made transparent. In C, you could just include , then do SYSCALL, and the library decides how to pass parameters transparently. BASIC could also easily make it transparent.

(It’s b q dot, not dot b q!)

One way to make it more flexible could be to have a ‘bit’ in the SWI number

That’s unnecessary; the platform the code is running on will be the same for both module and caller, so they just both have to use whatever mechanism is required by the processor.

This is what I meant by “We’ve really got to get away from thinking at the assembler level, registers and flags, and switch to thinking at the functional level.”