Portability and machine word lengths

vanevery@rbdc.rbdc.com (Brandon Van every)
Wed, 13 Sep 1995 03:32:52 GMT

          From comp.compilers

Related articles
Portability and machine word lengths vanevery@rbdc.rbdc.com (1995-09-13)
| List of all articles for this month |

Newsgroups: comp.compilers
From: vanevery@rbdc.rbdc.com (Brandon Van every)
Keywords: architecture, question
Organization: Red Barn Data Center, Winston-Salem, NC.
Date: Wed, 13 Sep 1995 03:32:52 GMT

I am trying to write some code that's portable across 32-bit and
64-bit architectures. To this end, I'm using GNU Autoconf to probe a
C compiler's fundamental type lengths before actually compiling. The
following typedefs are created according to whatever types fit the

char8 int16 int32 int64 float32 float64

Now the problem is that in _theory_, there's no guarantee that any of
these specific integer types is actually available. That means more
work coding. Or else the type may be available, but may only be
simulated and thus much slower than another type. Efficiency is
extremely important to the graphics algorithms I'm working on, so this
creates a temptation to write both 32 and 64 bit versions of a given
piece of code.

So what I want to know is, how much of an issue is any of this in
_practice_. What are the typical word sizes offered on today's 64-bit
workstations? I know plenty about the 32-bit machines, having
dissected GCC for info. In the 32-bit world, almost every machine
worth mentioning does:

char 8 bits
short 16 bits
int 32 bits
long 32 bits
long long 64 bits (simulated, if compiler supports this)

What's the equivalent laundry list for 64-bit machines? I don't care
about supporting _all_ 64-bit machines, just the mainstream ones: SGI,
Sun, HP, IBM, Dec Alpha, Apple, Intel(?). I think this amounts to
saying "I don't care about supporting VAXes" or other old hardware, or
possibly Crays, but I'm not sure exactly.

If people could tell me things like "in practice, you won't get a 32-bit
integer type on a 64-bit platform," or "you'll get it, but it will be
simulated with lots of extra shitfs and memory access hooey," or
"you'll get it, but you'll also get segfaults," then that's the sort
of thing I'd like to know.

If you can recommend any online resources that package up this sort of
info, that would be very helpful. However, saying "go read the Chip
List," which contains docs on nearly every chip in existence, really
isn't very helpful. I don't have time to chase through 1000's of
online docs to amass this info and come to my own conclusions. I'm
hoping to benefit from the wetware between your ears. :-)

Brandon J. Van Every


Post a followup to this message

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