BASIC and SYS

[Edit: TL;DR – It’s not actually a problem. Phew!]

I can’t help but notice that when BASIC assembles the SWI instruction for a SYS statement to plonk into [ARGP,#SWICODE] there is an absence of SWI XOS_SynchroniseCodeAreas. BASIC does do this once+ when it first initialises the SWICODE area at startup. [Edit: + See Jeffrey’s explanation below – just that once is sufficient to mark this location as containing a SWI instruction; the SWI ‘comment’ field doesn’t matter.]

Would it not be better for BASIC to call good old SWI OS_CallASWI(R12) (non-X for once!) rather than attempting to dynamically create code?

Does it only get away with this because it’s so good at thrashing the I-cache? One day that will no doubt bite if there’s a CPU with bigger I-cache or the I-cache eviction strategy changes.

Does OS_CallASWI returns the processor flags like a real SWI call would? The doc in the Wiki doesn’t mention anything.
If not you cannot use it for the form SYS … TO…;flags%.

Of course it does. :-) All the SWI (X)OS_CallASWI(R12) handler does is jump back to the SWI dispatch code with the SWI code in the correct register and proceed as normal though the desired SWI and its exit back to caller.

And SYS only passes R0-R9 to the SWI so either R10 or R12 would do, whichever fits BASIC best.

rather than attempting to dynamically create code?

Possibly one of the following:

• softload versions of BASIC are not guaranteed to be running on a machine with CallASWI(R12) available, and since it’s the same code that bakes both versions…
• if it ain’t broke, don’t touch!

there is an absence of SWI OS_SynchroniseCodeAreas

We’re probably lucky it hasn’t already bitten. That said, ye gods, imagine the penalty.

BASIC does do this – somewhat unnecessarily – when it first initialises the SWICODE area at startup.

Maybe it got stuck in the wrong place? BASIC is… an experience to try to read!

Hmm. I thought that we had RISC OS 3.1 with the usual suspect support modules as the minimum baseline target for objects crafted from the ROOL source?

Even if we did want to support RISC OS 3.1..3.6 without the CallASWI module loaded, it’d still be cheaper to test once then use the appropriate method. Certainly if it’s BasicVFP that’s being cooked, the target will support SWI OS_CallASWI(R12).

Aside: I found this amusing:

DOPLOT  SWI     XOS_Plot
        MOVVC   PC,R14
        SWI     OS_GenerateError

I can guess how that’s happened: Sophie would have added the SWI; MOVVC at the start of the existing PLOT routine which fired off a VDU 25 sequence – it would work faster on machines with New Arthur fitted but still work on old ones. At some point, that has been expunged.

I thought the simplest thing to provoke this – exercising the least amount of the BASIC interpreter code – might be the below. Remarkably seems to (visibly) work on my ARMX6 which I think has a 32KB L1 I-cache. Anyone with a Pi4 with larger L1 I-cache?

O%=256+ASC"O":K%=256+ASC"K"
10SYSO%:SYSK%:SYS3:GOTO10

I can’t help but notice that when BASIC assembles the SWI instruction for a SYS statement to plonk into [ARGP,#SWICODE] there is an absence of SWI XOS_SynchroniseCodeAreas.

That’s because “updating the SWI number of a SWI instruction” is one of the few situations in which XOS_SynchroniseCodeAreas isn’t needed.

The execution unit in the CPU doesn’t look at the SWI number. It’s the responsibility of the SWI handler code to load the instruction and extract the SWI number itself. So since it’s code loading it via standard LDR/LDRB, there are no coherency worries for the value that was written a few moments ago via STR/STRB.

However, the above is true only for AArch32. In AArch64 when a SWI instruction is executed the CPU will automatically put the SWI number into one of the CPU’s special registers. So for that value to be correct, cache maintenance would be required.

Very true!

And there are so few SWIs possible in AArch64 probably the only one to implement directly would be OS_CallASWIXMarksTheSpot.