Re: sizeof(int) in 64-bit C compilers

Duane Sand wrote:
> [how big are C ints and pointers on new 64 bit chips?]


Larry Rau wrote:
> I know DEC's Alpha OSF compilers defined sizeof(int)==32 and
> sizeof(long)==64. They also had a link option which foreced all
> "data" to be available within the 32 bit range. This proved to be not
> too useful -- pointers were still 64bit they just contained values
> which were in a 32bit range. I was supposed to be useful for porting
> but I found it usually just masked errors until later. They also, I
> believe, did modify their compilers in a later release to actually
> generate "32bit code" where pointers were really 32bit quantities, but
> I never used that compiler and could be wrong??


You're right. The -taso (Truncated Address Space Option) option for
the C compiler was introduced first. It was basically nothing more
than a hint to the linker to always place text and data segments in
address spaces which fit in a sign-extended 32-bit address. In this
mode:


sizeof(long) == 64
sizeof(void *) == 64
sizeof(int) == 32


Malloc() would, therefore, always create new memory regions which were
in the 32-bit region also.


This option was good for taking existing applications which were
written with 32-bit assumptions and giving them "the old smoke-test"
to see if they'd run. However, you'd still have no joy if the
application had code like this:


void some_func(int *ip); /* set the referenced int */


void *v;
int *ip = (void *)v; /* bad cast */


...
some_func(*ip);
...


which would end up setting only the low 32-bits of v. The most
significant 32 bits would not be a sign extension of the lower 32
bits. If v were later dereferenced as a pointer, chaos would ensue.
But _most_ applications weren't coded that poorly. <sigh>




Later, DEC introduced the -xtaso option which, in addition to the
linker options, put the compiler in this mode:


sizeof(long) == 64
sizeof(void *) == 32
sizeof(int) == 32


and most everything would work.




The worst disadvantage to either scheme is (was?) that one could no
longer use interesting things like mmap() since the OS didn't know the
application relied on a truncated address space. Or maybe that
restriction's been lifted. If so, you get the best of all worlds:
small pointers, big integers (and all of it quite fast too 8^).


(Note: Digital UNIX uses mmap() for the internal implementation of all
file operations but since it's hidden within the fopen/fread/fwrite
and friends, files can still be mapped into 64-bit space and still
function correctly in a 32-bit-only application.)


--
***********************
* Rick Kennell
* kennell@cs.purdue.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.