[ CCing H.J.
context:
the thread start:
http://www.mail-archive.com/xorg-devel@lists.x.org/msg27303.html
reply to: http://www.mail-archive.com/xorg-devel@lists.x.org/msg27338.html
]
> >>> What would you prefer?
> >>
...
> >> Is there any real benefit to "AMD64-x32" over simply x86-32
> >
> > Whole AMD64 ISA is accessible: twice as much registers (including xmm/ymm),
> > instruction extensions available only in "long mode".
> >
> > It helps help codecs embedded into browsers and players.
> > C calling convention uses registers (first six integer parameters go to
> > registers)
> > which reduces stack memory traffic.
> >
> > Quite nice comparing to what we have in ia32.
>
> So use AMD64 then.
>
> >> or AMD64 for X applications?
> >
> > Pointer memory footprint is on ia32 level. Saves Dcache and RAM for huge
> > programs
> > with large amount of references (like firefox and KDE).
>
> Few of the X.Org applications will fall into that set.
>
> In any case, if it's so useful, why not make a real ABI out of it, instead of
> breaking the existing AMD64 ABI defines? Just define __amd64_x32__ or
> whatever instead, don't break existing code that knows what __amd64__ means.
Hi H.J.!
What do you think of changing predefined __amd64__ define in gcc to something
distinct?
If it's not an option, how about adding one more define for those who like to
check
for this exact feature on all compilers (and not only gcc)?
So thread start's use case would look like
-#if defined(__amd64__)
-# define LONG64
-#endif
+#if defined(__amd64__) && !defined(__amd64_x32__)
+# define LONG64
+#endif
which would be less fragile for existing compilers.
Thanks!
--
Sergei
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
