integer types, sys calls, and stdio
Snoopy
seifert at mako.UUCP
Wed Jan 30 15:21:48 AEST 1985
In article <631 at turtlevax.UUCP> ken at turtlevax.UUCP (Ken Turkowski) writes:
>In article <1997 at mordor.UUCP> jdb at mordor.UUCP (John Bruner) writes:
>>Here at the S-1 Project at LLNL we are porting UNIX to our own
>>machine, the S-1 Mark IIA. The hardware is capable of operating
>>upon 9-bit, 18-bit, 36-bit, and 72-bit quantities, so we have
>>defined the following types:
>>
>> char = 9 bits (S-1 quarterword)
>> short = 18 bits (S-1 halfword)
>> int = 36 bits (S-1 singleword)
>> long = 72 bits (S-1 doubleword)
> ...
>>We can define our system calls to use "int" and "long" integers as
>>V7 does, but this means that we'll have to use 72-bit integers when
>>a 36-bit integer would nearly always suffice. This seems ugly to me.
> ...
>
>Chars have always been 8 bits, shorts always 16, and longs always 32.
I wouldn't bet my life on it. Look in K&R. (page 182 in my copy)
>I would suggest that you keep as close to this as possible. Int has
>varied between 16 and 32 bits; hell, why not make it 64? :-)
>viz,
>
> char = 9 bits (S-1 quarterword)
> short = 18 bits (S-1 halfword)
> long = 36 bits (S-1 singleword)
> int = 72 bits (S-1 doubleword)
"int" longer than "long"? You are hereby sentenced to program
in FORTRASH for six months!
----------- new (?) idea begins here --------------------
OK, here's my suggestion, which may not help John (Hi John!)
port existing code, but might help in the future.
Why not figure out how many bits each variable *needs*, and then
declare them accordingly:
int8 foo;
int16 bar;
int12 baz;
int9 buff[BUFFSIZ];
int18 blat;
Then when the mess gets compiled, the various size ints get changed
to the smallest possible machine entity size, on the machine
it's getting compiled for.
So then when you're porting some spiffo program developed on,
say, a pdp11 to say, a pdp8, with 12 bit words, "baz" fits nicely.
You don't have to *assume* that it really might need 16 bits.
"blat", which is just a tad too big for a 16 bit int, would fit
in a "short" on the S-1 Mark IIA. It it had been declared "long",
it would get 72 bits! (are we talking overkill, or what?)
(I *refuse* to use the CDC with it's 6 bit characters and no lower case
as an example, so there!)
If speed is more important than storage, one could use a "fast"
suffix:
int14f foobar;
This would clue the compiler/preprocessor/sed-script/whatever to
use the fastest size (if it fits), even if it fits in something smaller.
or, there's always:
register int14 foobar;
That's it. Pretty simple. (therefore it might work, but noone will
like it :-) ) Again, yes I realise this doesn't help with *existing*
code, but it would help to use it in new stuff, no? And it doesn't
require an extension to the language!
_____
|___| the Bavarian Beagle
_|___|_ Snoopy
\_____/ tektronix!mako!seifert
\___/
More information about the Comp.lang.c
mailing list