[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.020 / U:5.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site