> 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.
I don't consider `compatible with older machines' if the software
doesn't run anymore but only creeps along because of all the traps
of MMX instructions and the slower emulation of them.
software, that claims to be `compatible with older machines' should
use MMX instructions only for CPUs which support them, and use
well optimized non-MMX code for older CPUs!
you really should consider how many cycles a MMX instruction takes,
how much tim it takes to trap just that instruction, decode and emulate
it, and how many cycles the same code dor non-MMX CPUs would take
and you'll probably realize that emulating MMX isn't the best way
to make users of non-MMX CPUs happy...
> 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.
and there will be no longer any reasonable fast non-MMX code around
e.g. for image manipulation. no thanks :-(
since you'd be using MMX stuff only for some inner loops and special
routines, it should be no big deal to have two similar routines
in yoru application, one with and one w/o MMX without sacrifying
speed on older boxes..
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu