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

When you get an invalid instruction the kernel traps it and delivers it
as a signal to the process (which by default dies with 'illegal instruction'
and probably (core dumped). If you trap that signal SIGILL with your own
handler you can write code of the form

if(instruction_is_valid_mmx(x))
emulate_it();
else
{
signal(SIGILL, SIG_DFL); /* Die die.. */
raise(SIGILL);
}
> 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.

That bit is the issue. In the MMX case MMX is weird and wacky enough its
unlikely to get generally used except in stuff like graphics libraries

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans