You get a signal (SIGILL) if you try to execute a unknown insn. Declare a
handler for it in a library that you ld_preload, and emulate the insn in this
handler.
> as far as i could se the lib approach would end in calls for mmx-functions
> (or float functions maybe), and this would then end up in about ONE
> function call per opcode ??? (ok, that's worst case).
Yes. But look-ahead could probably be done, and since mmx insns probably
would be gathered, it will speed up a lot to emulate several at once, in one
trap. This method is used by the FPU emulator.
> this function call would even be done if mmx support is present in the
> cpu.
No, of course, you won't get a SIGILL on mmx capable cpus.
> what's that bad on a compiler option? mmx-users do have other processors
> than non-mmx users, the have other compilers (pcg pgcc, egcs, whatever),
> or at least other switches (-mamdk6 -m....). why not simply add mmx to the
> compiler, skip the emulator, make it a recompilation option, widen the use
> of autoconf / automake, and here we go?
>
> and -- NEVER distribute mmx binaries in publix without providing non-mmx
> ones.
I agree with you, but people may want to execute a Win$ binary (under Wine),
that is poorly written and assumes an MMX is present. We have already seen
such behaviour from certain "software" makers, to force you to buy high-end
hardware.
> (i'd like a reply that includes pointers to papers on trapping
> instructions into libraries or something if possible,)
man signal,
man ld.so,
/usr/src/linux/arch/i386/kernel/signal.c
/usr/src/linux/include/asm/sigcontext.h
/usr/src/linux/arch/i386/math-emu
Ok, after all this discussion, I'm going to try to implement something (just
for the fun, since it's completely useless at the moment). If someone wants
to help, mail me.
-- Sylvain- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu