Re: [AD] Bug in MMX linear_clear_to_color8 with asynchronous usage

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> Good point. A simple rearranging of instructions should do.

Surprisingly (at least for me), yes, that appears to be sufficient.

> That's no good. Allegro still supports targets that don't have FPUs
> (386, 486), so we must check for presence of an FPU before touching it.

Agreed.

> I'm not sure about this. The Intel instruction set manual mentions for
> fsave that: "After the FPU state has been saved, the FPU is reset to the
> same default values it is set to with the FINIT/FNINIT instructions (see
> ?FINIT/FNINIT?Initialize Floating-Point Unit? in this chapter)."
>
> So my guess is that the FPU is usable even without the call to emms.

Probably makes sense given that...

> emms is much faster than fsave.
> emms is 58 clocks on the PMMX and 11 (+6 for latency) on the P2 and up.
> fsave is 124 to 300 clocks on the PMMX and 143 on the PPro and up.

Oh My God! I didn't know that fsave/frstor are so slow. Now I understand why 
the IRQ stub doesn't save the FPU state.

I think we ought not patch the IRQ stub. The problem has existed with normal 
FP code from the very beginning, before the MMX code was added, and I guess 
that the decision not to save the FPU state was made knowingly by Shawn.

-- 
Eric Botcazou