> >> 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
cpu.
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
ones.
(i'd like a reply that includes pointers to papers on trapping
instructions into libraries or something if possible,)
thanx for reading,
kind regards, http://stud2.tuwien.ac.at/~e9525748/ 2:310/220.264
Peter-Paul Witta e9525748@student.tuwien.ac.at 436764605536@max.mail.at
SAMBA SUPPORT - FAX SOLUTIONS - INTRANET / EXTRANET - DBMS SQL SOLUTIONS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu