AMD Athlon64 Systems

[Mike A. Harris]

On Sun, 19 Oct 2003, Jakub Jelinek wrote:

>> As a side note - AMD64 supports 32bit pointers being used in
>> 64bit applications, although I'm not sure wether or not our gcc 
>> (or any for that matter) support this yet.  -mmodel=small 
>> alledgedly enables it, although I haven't tested that either.
>
>That's wrong. -mcmodel=small (which is BTW the default for -fno-pic
>code on x86_64-*-linux*) means that binary's code and data all fits into
>low 2GB of address space. Pointers are still 64-bit, as not pointers
>point to symbols in the binary.

Ok, however I did say "allegedly" indicating that I wasn't 
specifically sure.  The discussion of this option occured well 
over a year ago, and I assumed the information I'd been given was 
correct.  I haven't tested it.

Nonetheless, wether or not gcc has an option to enable 32bit 
pointers in 64bit applications, and what the invocation of that 
option is - if it exists at all - I'm not sure.  I am very sure 
however that AMD64 architecture does in fact support 32bit 
pointers in 64 bit applications, even if the gcc compiler can't 
do that.  It can be done in assembler if one wants to use it bad 
enough, or it could be added to gcc in the future.

It's quite obvious IMHO that most applications running on AMD64
architecture under a 64bit OS would benefit most from being
compiled with 32bit pointers (as most apps do not need access to
more than 4Gb of memory space), and 64bit native code (to get
access to the extended registers, etc.  This would minimize cache
footprint significantly, while allowing the compiler to do fancy
optimizations with the new registers that wouldn't be possible
with just the x86 ones.  Wether the 64bit size of the registers
would benefit the particular code performancewise to the good,
depends on the specific code however.  If the code doesn't have
any particular benefit of 64bit wide registers, then some cache
would be wasted yes.  However these processors have *gobs* of
cache compared to x86 CPUs, so the increased cache usage IMHO is
offset greatly by that to be negligible, and the benefits of the 
extra registers is more likely to make a difference than not.

In order to measure the performance difference of course one 
needs to either handcraft assembler, or invoke gcc with the 
proper option.  I was unable to find the proper option in the gcc 
info docs just now, so either I've missed it, it's not 
documented, or it isn't implemented in gcc.


>This is very different from the 32-bit ABI I was talking about.

Of course.  32bit pointers are useable right now, either via gcc
if it supports it (still not clear to me), or via assembler.  
The former would be preferred, as the latter is only
realistically viable for certian small optimization paths in
certain applications for all the same reasons assembler isn't
widely used in general.

I'd still like to be able to test 32bit pointers in 64bit apps 
widescale and compare to 32/32 and 64/64 though.

-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat