[MPlayer-dev-eng] [PATCH] x86_64 mmx/sse/3dnow optimisation support

[Michael Niedermayer]

Hi

On Tuesday 12 October 2004 20:23, Aurelien Jacobs wrote:
> On Tue, 12 Oct 2004 12:18:42 +0200
>
> Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > Hi,
> >
> > > -#ifdef ARCH_X86
> > > +#if defined(ARCH_X86) || defined(ARCH_X86_64)
> >
> > There are lots of these. From what I know, I find it incorrect to
> > define X86_64 as a separate architecture, those are "only" 64bit
> > extensions after all...
> > Think you would need to change less if you put the x86_64 case to the
> > x86 case, and just adding something like:
> >
> > if ("$host_arch" == x86_64); then
> > _def_arch += "#define ARCH_X86_64 1\n$_def_arch"
> > fi
> >
> > so that both ARCH_X86 and ARCH_X86_64 are defined then.
>
> Sure I could do this. But I thought It would be clearer to have
> distinct ARCH.
> I personnaly prefer considering x86_64 as a really different arch
> (having 64 bits addressing instead of 32 bits, is a big enough
> difference IMHO).
> Any other one with an opinion about diffining or not ARCH_X86 for
> x86_64 traget ?

yes, x86_64 is not a superset of x86 (there are some tiny things missing, and 
theres no binary compatibility), so its no extension and ARCH_X86 shoudl IMO 
not be defined on ARCH_X86_64
another way to justify this is that ARCH_X86 code will often not compile or 
work on X86_64 without a few (tiny) modifications

[...]

> > What are the changes in libvo/osd_template.c for?
>
> In 64 bits mode, x86_64 can't access to upper halves (ah, ch...)

this is wrong, it can (at least the docs claim so, i dont have a x86-64 
system), but there are some exceptions, like none of the new 8 registers may 
be used in the same instruction, anyway see the docs for details

[...]

-- 
Michael

"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire