Larry - Re:"it sounds like a difficult problem to overcome (particularly giving consideration to the original Pentium.."
Two issues are involved.
First, the way Intel has implemented the MMX on the Pentium - using the floating point pipe for MMX instructions - has resulted in some unfavorable trade offs.
This fact was discussed a long time ago, but about three months ago, it took on a life of its own. Basically, if a software program switches from an algorithm in which the Pentium is set in "MMX MODE", about 56 clock cycles (seems to be one cycle for each of the new MMX instructions!) are required to switch the Pentium back into floating point mode so that a floating point operation can be loaded and then executed.
These 56 clock cycles are dead time - they represent a real penalty for inter-mixing MMX and floating point instructions.
I believe that Intel has always acknowledged this and has provided guidelines to software developers to avoid, or minimize, these STATE switches - MMX <---> Floating Point.
Clearly, for some applications, this may be an unacceptable trade off, yet for others it may be quite acceptable. We will have to wait and see what kind of MMX optimized software is produced - and how they perform across the Pentium MMX, AMD's K6, and Cyrix's M2.
Of real significance is the Pentium Pro - or more appropriately, the Klamath. Only about 5 or 6 clock cycles are required to make the state switch - MMX <---> Floating Point. So, Intel may emphasize this chip as "the true multimedia chip" and hopefully the Pentium will go away quietly (and quickly!).
The second Issue - Context switches between programs while the Pentium is in one state and the new program assumes the opposite state - thereby mixing up a floating point instruction with MMX data, or vice-versa.
Is this an Intel problem or a problem of poorly coded software?
I tend to think it is the latter. A well coded code segment should preserve the state of the machine (as it encountered it) upon entry and restore the Pentium to this same state after it completes its execution, prior to exiting.
Similarly, after saving the machine state, it should force the Pentium into the desired state (MMX or Floating Point) and not make assumptions about this state.
Unfortunately, older software was probably written without any MMX awareness, so there are bound to be problems with these older programs when they interrupt MMX programs in progress.
Paul |
