>> Having any integers that are not the true 'natural' size for the
>> architecture (32bits for almost everything except ILP64 alpha) costs
>> code.
> FWIW, no one uses the Alpha in "ILP64" mode.  It's LP64, which is to
> say 32-bit int, 64-bit long,pointer, 64-bit long long.

How hard would it be to set up an alpha toolchain for which int and
long are 64 and long long is 128?

It'd need new values for int*_t and such, and a new (MD) type for at
least one of int{8,16,32}_t - or else dropping one of those types.
(I've always been annoyed by the nonportability of assuming a host
_has_ a (say) 16-bit unsigned type.)

I've also considered trying to arrange some way to get more or less
arbitrary-sized types, so you can get (say) a 19-bit signed integer on
any machine, with the compiler doing whatever is necessary to fake it
if the hardware doesn't have it.  __int_t__(19) perhaps, which you
could of course typedef int19_t to if you felt like it.  Nah, probably
more work than it's worth...though if you could do it for unlimitedly
_large_ types (__u_int_t(1000)?) it could be a great deal more useful.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B