RISC_OSLib and polling FP state

Why on earth, in 2015 and RISC OS 5, does RISC_OSLib’s polling functions fart around with managing the FP state?
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Lib/RISC_OSLib/rlib/s/poll?rev=4.6

I discovered this monstrosity while patching up Ovation (not Pro!) to build on the Pi and was shocked (shocked, I tell you!) to discover that RISC_OSLib was doing the exact same thing. Surely we aren’t under some mass delusion where RISC OS 2 is still being supported?!?

Accordingly, I threw away the code and wrote:

wimp_poll
        ; greatly simplified poll routine
        ; R0 = poll mask
        ; R1 = pointer to event structure
        ORR    R0, R0, #1<<24   ; Wimp to save FP context
        ADD    R1, R1, #4       ; point to eventstr->data
        SWI    XWimp_Poll
        SUB    R1, R1, #4       ; point back to eventstr
        STR    R0, [R1, #0]     ; store the reason code
        MOVVC  R0, #0           ; return NULL if no error
        MOV    PC, R14

(and ditto for wimp_pollidle)

Wouldn’t that be more appropriate for……well, any Wimp that isn’t RISC OS 2?

I discovered this monstrosity while patching up Ovation! to build on the Pi

Rhooooo :)

Well, since Ovation is an APDL product (the late David Holden), there is the little issue of distribution. Namely that I can’t. Well, I can pass on the modified sources, just as I got the originals myself; but there’ll be no executables, no templates, no… you get the idea – at this time you’ll need a copy of Ovation (for the resources) and the DDE to build the project.

Initial info here: http://www.heyrick.co.uk/blog/index.php?diary=20151023

This weekend’s mods described here: http://www.heyrick.co.uk/blog/index.php?diary=20151025

Kind of understandable if the underlying app is expecting the FPU to be in the same state on return. The code does state Only f4..f7 defined preserved over procedure call

I smiled when I read emulated a lot faster than writeback and then immediately spotted the surrounding code wasn’t optimized.

save_fp_state
        RFS     a2                      ; read FP status
        STR     a2, [sp, #-4]!
        MOV     a2, #0
        WFS     a2
        SUB     sp, sp, #4*12           ; emulated a lot faster than writeback
        STFE    f4, [sp, #0*12]
        STFE    f5, [sp, #1*12]
        STFE    f6, [sp, #2*12]
        STFE    f7, [sp, #3*12]
        MOV     pc, lr

; v1, v2 trashable
restore_fp_state
        MOV     v1, #0
        WFS     v1
        LDFE    f4, [sp, #0*12]
        LDFE    f5, [sp, #1*12]
        LDFE    f6, [sp, #2*12]
        LDFE    f7, [sp, #3*12]
        ADD     sp, sp, #4*12           ; emulated a lot faster than writeback
        LDR     v1, [sp], #4
        WFS     v1
        MOV     pc, lr

Could be one instruction less:

save_fp_state
        RFS     a2                      ; read FP status
        STR     a2, [sp, #(4*12)-4]!
        MOV     a2, #0
        WFS     a2
        STFE    f4, [sp, #(0*12)+4]
        STFE    f5, [sp, #(1*12)+4]
        STFE    f6, [sp, #(2*12)+4]
        STFE    f7, [sp, #(3*12)+4]
        MOV     pc, lr

; v1, v2 trashable
restore_fp_state
        MOV     v1, #0
        WFS     v1
        LDFE    f4, [sp, #(0*12)+4]
        LDFE    f5, [sp, #(1*12)+4]
        LDFE    f6, [sp, #(2*12)+4]
        LDFE    f7, [sp, #(3*12)+4]
        LDR     v1, [sp], #(4*12)+4
        WFS     v1
        MOV     pc, lr

but there’ll be no executables, no templates, no… you get the idea

Perhaps that new apdl people will be happy to provide this version :)

Kind of understandable if the underlying app is expecting the FPU to be in the same state on return.

Not really so understandable – all that code can be replaced by:

   ORR   R0, R0, #1<<24 

Why is RISC_OSLib duplicating something the Wimp can do for itself?

Not really so understandable – all that code can be replaced by:

Ah…I understand now. I didn’t realise the Wimp could save the FPU state via the Poll flags. Yes, I agree with you then, let the Wimp handle it.

Why is RISC_OSLib duplicating something the Wimp can do for itself?

Maybe because RISC_OSLib is that old¹ that it pre-dates that feature? Or maybe it was intended as an easier access?

¹ Open box of code and pterodactyls emerge and circle?

Pterodactyls indeed. I wonder how much other outdated cruft is kicking around?

I wonder how much other outdated cruft is kicking around?

Most of R_OL ?