Messages in this thread | | | From | "Adam J. Richter" <> | Date | Wed, 17 Jun 1998 12:36:37 -0700 | Subject | Re: MMX emulator ? |
| |
Nathan Hand (nathanh@chirp.com.au) writes: >On Tue, 16 Jun 1998, Jeffrey Hundstad wrote: >> 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. > >100% agreement.
I agree, at least ideally. MMX emulation is not a performance issue. The point is that you want MMX instructions simply to run, even if 100X slower. You do not always have source code and the original build environment available, and if you accidentally call a subroutine that contains an MMX instruction, you do not want that to wipe out your program. However, there should still be a way to check if a processor natively supports MMX, because anything that makes serious use of MMX instructions and is intended to run on non-MMX hardware will be written as "if(mmx_present) {do_it_using_mmx();} else {do_it_the_standard_way();}".
Ideally, MMX emulation should be a demand loaded module, so it will not take up much RM when it is not needed (even if 100MHz ECC SDRAM is down to $1.75/MB).
On the other hand, because I have not yet seen MMX instructions seep into any user code that I am aware of, I would not say that MMX emulation is currently a priority. I am not even aware of any other x86 operating system that does it. So, as usual, I think it's really up to those who consider the feature a priority to write the code.
-- Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205 adam@yggdrasil.com \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |