Rick's b.log - 2020/03/18
It is the 3rd of May 2024 You are 3.134.104.173, pleased to meet you!

SharedCLibrary versions

Well, a compiled program has a "stubs" part stuck at the end which does all the interfacing with the library, and part of it looks like this:

What we can see from this is that the minimum that is required is to have SharedCLibrary 5.17 and FPEmulator 4.03.

The current library version is something like 6.03, and it looks as if a good many programs ask for 5.34 (but not all, some want later) so what is actually different and why would you want to specify a version?

The answer is simple - you'd want to require a version of the library that offers the features that you need.

Briefly:

• Versions prior to 5.27 have a variety of serious 32 bit issues. Probably shouldn't be used.
  If you're interested in a useful 32 bit friendly version, you should ask for 5.44 or newer.

• Versions prior to 5.52 contain no or partial support for C99 features such as long long, complex numbers, etc etc.
  If you use these things, you'll probably want 5.52 or later.

Versions following are less "major change", so will simply be listed with the salient points. No mention is made of RISC_OSLib changes, as you ought to have the latest version if you're using a recent DDE.

• 5.60 now looks up the location of the special CLib words, instead of hacking around in page zero.
• 5.61 uses SMULL/UMULL/CLZ in the maths code. This probably only applies to ROM builds as legacy hardware (probably everything pre-StrongARM) won't have those instructions.
• 5.64 includes support internally for 64 bit file pointers, in readiness for when the filing system is able to cope with it...
• 5.69 supports locale support for selecting timezones (done in 5.68) and changes to mktime() to support this.
• 5.76 fixes scanf() so it'll fail when no match occurs.
• 5.88 has an option to use LDREXB/STREXB instead of SWP and SWPB. Soft load versions will look at the processor to determine whether or not it's safe to use swap, ROM builds will be built for the specific architecture.
• 5.90 fixes localtime() to return the correct time if the timezone is not the first for the territory (my fix ☺).
• 5.91 provides enhancements so clients can receive optimal routines (where possible) according to their processor type.
• 5.93 removes some unnecessary cache sync calls, to optimise on SMP ROMs.
• 5.95 fixes some "abort while in abort handler" problems due to stack pointer/limit values being invalid.
• 5.97 includes enhancements to try to avoid blocking callbacks (the unkillable while(1) {} loop in a TasWindow...

With this in mind, everybody ought to be using the latest version of CLib, however for your own programs...

• 5.44 should be the absolute minimum that you ask for in your RMEnsure.
• 5.52 if you want C99's enhancements, 64 bit integers, etc.
• 5.90 if you need working support for alternative timezones.

Your comments:

Gavin Wraith, 18th March 2020, 22:40

Many thanks for this, Rick. Let us hope it will not be too long before CLib also supports VFP and Neon.

David Pilling, 22nd March 2020, 02:42

I never seem to do the right thing - perils of being involved for so long - RMEnsure a version and someone will decide one should not. Interesting to read of the differences though - I did not appreciate those.

Rick, 24th March 2020, 21:42

Yes, I hope CLib soon supports VFP, as emulating FP on a machine with it in hardware (and hundreds of times faster) is rather untenable.    Unfortunately it is not as simple as plugging in a different set of instructions. Unlike FPE which only requires some registers to be preserved, VFP uses contexts. Also, the byte ordering of the FP values in memory is the other way around, so anything that works directly with that (casting, printf, etc) will need versions that understands both VFP (for new apps) and FPE (for everything else).

Rick, 24th March 2020, 21:48

FP values are defined by IEEE aren't they? Aside from byte order, they're the same thing, yes?  Assuming so...    Personally, the way I'd do it is to write all the FP routines to work with VFP values. And have a flag set by the application if it supports VFP.  Then, upon dealing with an FP value, if the flag is NOT set, then flip the byte ordering. In this way, the default is for direct support of VFP for speed, and any time lost due to constant byte flipping for FPE will be negligible compared to using the maths emulator itself...