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