Subject: Re: emuns on ARM: What should we do?
To: <>
From: David Laight <>
List: tech-toolchain
Date: 01/21/2002 22:44:17
der Mouse wrote:
> >> 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.

OK Someone was definitely doing a 64bit OS that was ILP64, it wasn't
Sun, HP or IBM - so it must have been DEC.  Dunno which type they lost -
short must have been either 16 or 32bit.
> 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.)

C doesn't need all of them, only the [u]int_leastN_t types are mandatory
(was reading the C standard this morning).
> 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 C standard defines types [u]intN_t without any regard for the value
of N. For some values of N the types are mandatory.  There is nothing to
stop you writing a compiler that supports [u]intN_t for all values of N.

How about writing a C compiler for something like the ICL System 25? 
This has a Ascii / BCD arithmetic engine!  Supporting integers up to 10
digits with sign overpunch.  The original (Singer system 10) system had
4 digit addresses, these were expanded by 3 binary bits and later by 2
more - giving a maximum address of 320,000 bytes.  There are no bitwise
operators, and no binary arithmetic.  Each intruction is 10 bytes.  The
original disk had 100 byte sectors....

Maybe not...