Re: [AD] - MMX Linear clear

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Erik Sandberg <erik.sandberg@xxxxxxxxxx> writes:
> >Blitting is a problem, because it is used for displaying the mouse 
> >cursor, which means it has to be interrupt safe, and you can't use MMX 
> >(or indeed any FPU code) in an interrupt context.
> 
> Yes, it should be possible, if just FSTENV is called right before the
> FP/MMX code, and FLDENV right after. FLDENV will restore the FPU state to
> its previous state, so it will be possible to do anything between those
> instructions (a good start would be to reset the FPU, which probably is
> done with FINIT or EMMS).
> 
> The FSTENV/FLDENV pair might already be included in the interrupt handler,
> in that case all you need to do is to insert a FPU reset instruction (which
> btw isn't needed with MMX).

The problem is that saving and restoring the FPU state is painfully slow, 
especially on older processors. We don't do it in the interrupt wrappers for 
performance reasons, and likewise it would be a shame to do that on every 
single blit() call: I suspect that when copying something small like say a 
32x32 tile, the save/restore overhead would more than compensate for any 
gains of using MMX instructions!

I'd rather have some mechanism to detect when the code is running inside an 
IRQ handler, and avoid using the MMX routines at all in that case. It's only 
a very small subset of functions (those that are used in displaying mouse 
cursors) that need to work inside timer handlers in any case, so this isn't 
a widespread problem.

The first step, though, is for someone to actually write some MMX code and 
see whether it really is faster. This was tried before, and the results were 
disappointing...



--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."