Of possible interest: fast UTF8 validation

Walter Bright newshound2 at digitalmars.com
Wed May 16 16:54:19 UTC 2018


On 5/16/2018 7:38 AM, Ethan Watson wrote:
> My preferred method though is to just build multiple sets of binaries as 
> DLLs/SOs/DYNLIBs, then load in the correct libraries dependant on the CPUID test 
> at program initialisation.
I used to do things like that a simpler way. 3 functions would be created:

   void FeatureInHardware();
   void EmulateFeature();
   void Select();
   void function() doIt = &Select;

I.e. the first time doIt is called, it calls the Select function which then 
resets doIt to either FeatureInHardware() or EmulateFeature().

It costs an indirect call, but if you move it up the call hierarchy a bit so it 
isn't in the hot loops, the indirect function call cost is negligible.

The advantage is there was only one binary.

----

The PDP-11 had an optional chipset to do floating point. The compiler generated 
function calls that emulated the floating point:

     call FPADD
     call FPSUB
     ...

Those functions would check to see if the FPU existed. If it did, it would 
in-place patch the binary to replace the calls with FPU instructions! Of course, 
that won't work these days because of protected code pages.

----

In the bad old DOS days, emulator calls were written out by the compiler. 
Special relocation fixup records were emitted for them. The emulator or the FPU 
library was then linked in, and included special relocation fixup values which 
tricked the linker fixup mechanism into patching those instructions with either 
emulator calls or FPU instructions. It was just brilliant!




More information about the Digitalmars-d mailing list