SharedCLibrary on Raspberry Pi contains the SWP instruction
Graeme (8815) 103 posts |
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! |
David J. Ruck (33) 1585 posts |
Well, we’re not going anywhere! |
Stuart Swales (8827) 1323 posts |
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. |
Chris Mahoney (1684) 2160 posts |
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 1 |
Rick Murray (539) 13747 posts |
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. |
Rick Murray (539) 13747 posts |
I really don’t like the “official” advice to RMEnsure a version and then RMLoad if necessary. 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. 1 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… |