SharedCLibrary on Raspberry Pi contains the SWP instruction

I have tried a fresh install of the Raspberry Pi RO 5.30 download to double-check this.

When you install RO 5.30 you get two copies of SharedCLibrary. One is in the ROM and the other is in !System in the 500 folder (named clib). Both are version 6.22 and both dated 29 Nov 2023.

The version in the ROM seems to be fine.

The version in !System contains the SWP instruction and seems to be a much smaller file. The SWP instruction does not work on Pi 3 and 4 models, maybe others. Not without my ACE module (ARM Chip Emulator), now available at http://www.ro32.co.uk (shameless plug and new website address)

It is incredibly highly unlikely to cause an issue (unless you are me!) since most RmLoad commands should have a RmEnsure before it and the ROM (working) version is already running by default.

I am interested to know if this is an oversight or a deliberate decision? If it is deliberate, I am really fascinated what the the reason is.

If anyone wants to know how I discovered this… well… it’s a long story!

Well, we’re not going anywhere!

since most RmLoad commands should have a RmEnsure before it

And most especially in the SharedCLibrary department.

The SharedCLibrary in modern ROMs is conditionally compiled/assembled for best performance on that platform and should not be overridden by softloaded modules which are targetted to the lowest common denominator CPU. Except, as you’ve found, SWP ain’t supported any longer on ARMv8.

Does the version in System attempt to use the SWP instruction when running on a recent platform? Could it conceivably use it on old machines (where it might be faster or more convenient on some hardware) and go down a different branch on newer machines?

Edit: I just had a quick nosey at it and ran into a SWP wrapped in an if (_swp_available), with it using a (presumably slower) C-native swap¹ otherwise. I can’t guarantee that every reference to SWP is like that, but there’s been at least some thought put into it.

¹ int oldValue = *location; *location = newValue; return oldValue;

Versions in System are lowest common denominator, whereas the one in ROM is tailored to your machine. It is likely that they’re both the same version as the Harddisc4 resources are up to date with the ROM right now, thanks to a recent stable release.

The actual code in the library is…painful. Lots of build options due to the many years of legacy.

[ {CONFIG}=26
Arm2Swp ; like SWP a1,a1,[a2] but corrupts a3, lr and flags
        SWI     IntOff
        LDR     a3, [a2]
        STR     a1, [a2]
        SWI     IntOn
        MOV     a1, a3
        MOV     pc, lr
 |
AcquireMutex
        FunctionEntry
        MOV     a2, a1
  [ SupportARMv6
   [ NoARMv6
        LoadStaticBase a4, ip
        LDR     a1, [a4, #O__swp_available]
        TST     a1, #2 ; does CPU support LDREX?
        BEQ     %FT03
   ]
        MOV     a3, #0
  ]
        B       %FT02
  [ SupportARMv6
01      MOV     a1, #6
        SWI     XOS_UpCall
02      LDREX   a1, [a2]
        STREX   a4, a3, [a2]
        TEQ     a4, #1
        BEQ     %BT02
        TEQ     a1, #0
        BEQ     %BT01
        Return
  ]
  [ NoARMv6
01      MOV     a1, #6
        SWI     XOS_UpCall
02
03      MOV     a1, #0
        SWP     a1, a1, [a2]
        TEQ     a1, #0
        BEQ     %BT01
        Return
  ]
 ]

At any rate, there’s no reason to load the one on disc (built for every system) if the ROM version (built for that machine) is the same.

since most RmLoad commands should have a RmEnsure before it

I really don’t like the “official” advice to RMEnsure a version and then RMLoad if necessary.
One cannot easily tell ¹ if any particular CLib is softloaded or not, and it has never been safe to softload over a softload.

Granted, it’s not a big problem as apps shouldn’t contain their own CLib and you shouldn’t have multiple different versions in System, but still…

…the sensible official advice ought to be RMEnsure followed by Error to alert the user to a potential issue.

¹ Call OS_Module to get the base address and see if it’s in the RMA or the ROM, but note that we’re now into writing code rather than simply calling commands in an Obey file…