[lkml]   [1998]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: f@#$ing MMX emulator
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?

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).

this function call would even be done if mmx support is present in the

this sounds much like java (emulate even if it's possible in hardware).

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

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

kind regards, 2:310/220.264
Peter-Paul Witta

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.029 / U:2.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site