[xproto: PATCH] Xmd.h: amd64-x32 ABI defines sizeof(long) == sizeof (void*) == 4

[Sergei Trofimovich]

[ 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20111221/5c281ded/attachment.pgp>