Mike Farnsworth wrote:
Was it actually rewriting the executable code to call the alternate
functions (e.g. a exe load time decision, patch the code in memory,
and then run)? I thought that sort of thing would run into all sorts
of runtime linker issues (ro code pages in memory, shared libs that
also need the rewriting, etc.), but then again, they do that with JIT
compiling all the time.
It's much simpler than that. Some C:
=========================================
void foo_with_FPU();
void foo_without_FPU();
void (*foo)();
void main()
{
has_fp = doesCPUhaveFPU();
if (has_fp)
foo = &foo_with_FPU();
else
foo = &foo_without_FPU();
... execute app ...
(*foo)();
... execute more app ...
}
=========================================
#if WITH_FPU
#define FOO foo_with_FPU
#else
#define FOO foo_without_FPU
#endif
void FOO()
{
... do some floating point calculations ...
}
==========================================
dmc -DWITH_FPU -c foo.c -f -ofoo_with_fpu.obj
dmc -c foo.c -ofoo_without_fpu.obj
dmc app.obj foo_with_fpu.obj foo_without_fpu.obj
===========================================
Hope that makes it clearer. No runtime linking, no runtime compiling, no
self-modifying code, etc.
A better way to do it is to put your FP code behind a class interface,
then have derived classes implement them, compiled with different
instruction set options. At runtime, decide which derived class to use.
