SWI flag preservation

I’ve somewhat ignored this issue in ADFFS to date, but need to now make a start on it. I’m going to start on the assumption that all SWI’s preserved the N, Z and C flags up to RO5, so need to know exceptions to this rule.

From a scan of the RO3 PRM’s, I know about the ones below, are there any others?

OS_Byte 138 – alters C
OS_Byte 145 – alters C
OS_Byte 152 – alters C
OS_Byte 153 – alters C
OS_ValidateAddress – alters C
OS_ClaimScreenMemory – alters C
OS_Word 15,15 – alters C
OS_Word 15,24 – alters C
OS_GSRead – alters C
OS_GSTrans – alters C
OS_ReadModeVariable – alters C
OS_CheckModeValid – alters C
OS_ReadC – alters C
OS_Word 0 – alters C
OS_ReadLine – alters C
OS_ReadEscapeState – alters C
OS_Confirm – alters C, Z
OS_GBPB – alters C
DeviceFS_ReceivedCharacter – alters C
DeviceFS_TransmitCharacter – alters C
OS_SerialOp 3 – alters C
Territory_Exists – alters Z
Territory_Collate – alters N, Z, C
OS_CallAVector – dependent on Vector called

All SWI’s – alter V

When you say “up to RO5”, I’m assuming you’re already aware of this:

On a 32-bit system, SWIs are no longer expected to preserve the N Z and C flags. They may still set/clear them to return results. 32-bit code should not assume that SWIs preserve flags. Requiring flag preservation would impose an unacceptable burden on SWI dispatch. This effectively re-specifies all SWIs by changing the default rule in PRM 1-29. Also, it becomes impossible for SWIs outside the Kernel to depend on the NZCV flags on entry. SWIs inside the Kernel, such as OS_CallAVector, can still manipulate flags freely. This should not be an onerous restriction; it is impossible to specify entry flags for SWIs in C or BASIC, for example.

When you say “up to RO5”, I’m assuming you’re already aware of this

Sorry, I should have explained that when ADFFS’ JIT is providing a RISCOS 3.X or 4.X environment to an app, it needs to preserve flags across SWI’s to match previous behaviour.

Requiring flag preservation would impose an unacceptable burden on SWI dispatch

I never quite understood the reasoning behind this as you have to go out of your way to alter SPSR in SWI dispatch – flags are preserved by default if you exit via MOVS PC, R14 or LDMFD R13!, {PC}^

flags are preserved by default if you exit via MOVS PC, R14 or LDMFD R13!, {PC}^

I should add briefly that these instructions are for system level code. They are “unpredictable” in user mode code.

Yes, I had always thought that there was some sort of complicated technical reason for not preserving flags – indeed the Iyonix 32 bit technical information says “Requiring flag preservation would impose an unacceptable burden on SWI dispatch.”.

However, having looked into it a lot more deeply than I did maybe a decade ago, I cannot see anything obvious that would require an entire API change, except perhaps that there is some sort of peculiarity in how RISC OS deals with SWIs.

Quoting from the ARM System Developer’s Guide (p391):

coreSWIHandler
        STMFD  sp!,{r0-r12,r14}    ; save context
        LDR    r10,[r14,#-4]       ; load SWI instruction
        BIC    r10,r10,#0xff000000 ; mask off the MSB 8 bits
        MOV    r1,r13              ; copy r13_svc to r1
        MRS    r2,spsr             ; copy spsr into r2
        STMFD  r13!,{r2}           ; save r2 onto the stack
        BL     swi_jumptable       ; branch to the swi_jumptable

[...]

        LDMFD  r13!,{r2}           ; restore the r2 (spsr)
        MSR    spsr_cxsf,r2        ; copy r2 back to spsr
        LDMFD  r13!,{r0-r12,pc}^   ; restore context and return

This is their mini “SLOS” operating system example aimed at the ARM7TDMI (in 32 bit mode).

I must admit to being surprised at seeing multiple load/store on a single register, though for the purposes of example, maybe
STMFD r13!,{r2} ... LDMFD r13!,{r2}
is clearer than
STR R2, [R13, #-4]! ... LDR R2, [R13], #4 ¹
?
Additionally, the use of sp! once then r13! afterwards is verbatim from the book. ²

¹ My preference is upper case register names and instructions, lower case labels, and whitespace like spaces between parameters and the like.

² “sp” is used at the beginning, setting up the stack positions (p386) and setting up the process control block (p387). From then on, “r13” is used, except this one time in the SWI dispatch.

Interestingly, the actual build code is slightly different to that given in the book:

coreSWIHandler

     STMFD   sp!,{r0-r12,lr}       ; Store registers
     LDR     r10,[lr,#-4]          ; Calculate address of SWI instruction
     BIC     r10,r10,#0xff000000   ; Mask off top 8 bits
     MOV     r1,sp	           ; second parameter to C routine...
                                   ; is pointer to register values.
     MRS     r2,SPSR               ; move the spsr into gp register
     STMFD   sp!,{r2}              ; store spsr onto the stack. 
                                   ; This is only really
                                   ; needed in case of nested SWI's
     BL      swi_jumptable         ; call C routine to handle SWI
     LDMFD   sp!,{r2}              ; restore spsr from stack into r2
     MSR     SPSR_cxsf,r2          ; and restore it into spsr.
     LDMFD   sp!,{r0-r12,pc}^      ; restore registers and return.

Does the same thing, but is written more consistently; and more commentary.