Re: MMX emulator ?

Anthony Barbachan (barbacha@trill.cis.fordham.edu)
Fri, 19 Jun 1998 22:25:19 -0400


-----Original Message-----
From: Harald Koenig <koenig@tat.physik.uni-tuebingen.de>
To: linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>
Date: Thursday, June 18, 1998 11:40 AM
Subject: Re: MMX emulator ?

>On Jun 18, Anthony Barbachan wrote:
>
>> 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.
>

An MMX capable program would not necessarily creep along on a non-MMX
system. Especially if it is only used sporatically or occasionally or the
program doesn't tax the CPU and is running on a high end non-MMX processor.

>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 :-(
>

I rather doubt this, as most code would probably be in some language.

>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..
>

Yes but you would be sacrificing some extra CPU cycles on MMX systems.

>
>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
>

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