On 2015-12-22 18:37:30 +0100, Henrik Gramner wrote:
> On Tue, Dec 22, 2015 at 5:41 PM, Janne Grunau <[email protected]> wrote:
> > I found HTML copy from 1999 of Intel's manual(1) which says that
> > cvtpi2ps with a memory location as source doesn't cause a transition to
> > MMX state. The current documentation for cvtpi2pd (packed int to packed
> > double conversion) says the same. Valgrind wasn't following that that
> > until Vitor reported it as #210264(2) in 2009 and it was fixed in (3).
> > As Julian Seward says in the commit message the situation is a little
> > bit fishy.
> 
> Intel's current documentation is very clear on cvtpi2ps: "This
> instruction causes a transition from x87 FPU to MMX technology
> operation".

every tested silicon (nothing ancient or SSE only though) and the copy 
of the manual from 1999 (Order Number 243191) (Pentium 3 and SSE were 
intruduced 1999) disagree. The instruction reference manual from 2002 
(Order Number 245471-006) misses the comment. But that could easily be 
an edit error. The comments from the end of the instruction description 
were removed and the main description was extended.

cvtpi2pd had initially the same language as cvtpi2ps wrt the mmx state 
transition and was changed between 2006 and 2010.

> For cvtpi2pd it does point out that a state transition only happens
> when the source is an MMX registers. I'm guessing that this difference
> in behavior is due to the fact that cvtpi2ps is SSE while cvtpi2pd is
> SSE2.

That seems unlikely given that the manual from 1999 clearly says that 
the transition only happens if MMX regs are used. I think it's possible 
that a CPU designed/introduce between 1999 and 2002 required the state 
transition. Athlon-XP and Pentium4 would be worth checking.

Since it will probably take ages to get this resolved: adding a emms 
before the return of int32_to_float_fmul_scalar_sse is enough for all 
x86 systems/calling conventions?

Janne
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to