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

Duane Sand wrote:
>The Mips/SGI compilers define "int" as 32 bits in 32-bit-pointer
>code, and 64 bits in 64-bit-pointer code.


streich@roo.mti.sgi.com (Mark Streich) writes:
>This is incorrect. "int" is always 32 bits in either 32- or 64-bit
>pointer code.


Hmmm. Does this depend on which SGI compiler is used?


SGI's compiler group recently gave Tandem a document on the 64-bit ABI
and an associated new (incompatible) 32-bit ABI, corresponding to the
new (non UCode) compilers. This doc definitely requires that all
integral arguments are unconditionally promoted to 64-bit width by all
callers, in argument registers and in memory-resident argument lists.
(As if "int" were defined as 64 bit.) I assumed that this change was
being motivated by a new definition of "int". I didn't go check my
assumption on an SGI box; sorry.


Now that you point it out, I see that this arg promotion could be done
for arbitrary reasons even if this instance of the C language doesn't
want it; the callee can always ignore the added widths. But if so,
this unnecessary widening of all args into 64-bit chunks seems like a
dumb idea, creating an incompatibility with existing object code for
no technical reason. IMHO.


Here's a possible rationale: the new ABI is object-code call
compatible with both flavors of C; the current one in which "int" is
always 32 bits, and potential future ones in which "int" is made
larger, as maybe needed someday by some customers. Of course, the two
C runtime support libraries couldn't interoperate reliably, eg
printf(). But at least individual user-coded C functions could call
functions of the other ilk.


Another rationale would be for preparing the ground for possible
future chips that execute 64-bit load/stores in fewer cycles than
32-bit load/stores. But no chip that runs WinNT is going to make that
mistake.




--

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