>On Tue, 16 Jun 1998, Jeffrey Hundstad wrote:
>
>> > i = detect_MMMX();
>> > if !i then usenormalstuff=1;
>> > else usemmx=1;
>
>> If you can assume the MMX functions are there then EACH application
>> doesn't have to emulate all of the MMX stuff itself if it doesn't have
>> the REAL hardware.
>
>> This should be treated EXACTLY like the Floating Point hardware... at
>> least in my opinion.
>
>The 'normal stuff' in a real application that cared about
>decent speed would NOT be emulating the MMX instructions, but
>would do things differently. MMX is all about speed. I'd
>expect emulated MMX to be far slower than writing the code
>optimally using the instruction set available on a non-MMX
>CPU. And this is not counting the overhead from trapping the
>MMX opcodes.
>
The MMX emulation code could "optimally use the instruction set available on
a non-MMX CPU's". Beside MMX emulation would allow a programmer to optomize
for the latest CPU's while remaining compatable with older machines.
>If writing an MMX emulator leads to application programmers
>being lazy and just doing MMX versions of their apps, because
>"MMX is always available on Linux", then you have made a great
>disservice to the users.
>
This argument could also be made about the FP emulation and also the various
libraries. Reusing code is suppose to be a virtue in programming. Why
force everybody to reinvent the wheel. Beside an MMX instruction replaces
what previously had to be a block of code. One MMX instruction would be
much, much easier to debug, understand, optomize, and write than the
equivalant block of code. Thus MMX emulation could lead to cleaner and
overall faster code.
>Johan Myreen
>jem@iki.fi
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu