>Followup to: <199806162200.RAA05382@mail.mankato.msus.edu>
>By author: Jeffrey Hundstad <jeffrey.hundstad@mankato.msus.edu>
>In newsgroup: linux.dev.kernel
>>
>> no....
>>
>> 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.
>>
>
>Your opinion is, in many ways, flawed. The cost of doing
>floating-point on non-FP hardware is such that the cost of emulation
>is not a significant overhead. The same doesn't apply for MMX, which
>is an integer optimization. Simply put, emulated MMX is too slow to
>be used (typically, it will take over 500 cycles to do the two context
>switches you need for emulation, and no MMX-instruction-equivalent is
>even close to that.)
>
This might be true but MMX implementation in an OS was suppose to be
transparant to applications and handled in the exact same way FP operation
are. Unless we want users to occasionally (if not frequently) have
applications die with invalid opcode exceptions MMX will probably eventually
have to be included into the kernel. At least this will allow us to
optomize MMX instruction execution on non MMX machines and have consistant
MMX performance on those machines. Futhermore programmers will be able to
easily include MMX instructions in their apps without having to worry about
the presence of an MMX processor.
> -hpa
>--
> PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
> See http://www.zytor.com/~hpa/ for web page and full PGP public key
> I am Bahá'í -- ask me about it or see http://www.bahai.org/
> "To love another person is to see the face of God." -- Les Misérables
>
>-
>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