[lkml]   [1998]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: f@#$ing MMX emulator
On Sat, Jun 20, 1998 at 04:02:43AM +0200, Peter-Paul Witta wrote:
> On Fri, 19 Jun 1998, Anthony Barbachan wrote:
> > >> For god sakes peoples.. The reason the fpu emulator is in the kernel is
> > >> because it HAS to be in there. Without it you're up the proverbial creek
> > >
> > >No it doesnt. It can be in the C libraries
> ok. good. "it can be done". could someone kindly point out how? patterson
> /hennesey talked about "trapping opcodes (missing microcode) into the
> OPERATING SYSTEM. how can you trap bad opcodes in a library?

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

> 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

> (i'd like a reply that includes pointers to papers on trapping
> instructions into libraries or something if possible,)

man signal,

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.076 / U:1.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site