chris@umcp-cs.UUCP (Chris Torek) (08/09/85)
>In any case, most experienced C programmers will use "short" when 16 >bits is known to suffice and "long" when 32 bits are needed. I beg to differ: I tend to use "int" when 16 bits will suffice and I'm not concerned with data space, and I think many others would do the same, especially since the 4BSD Vax PCC compiler (and probably many other compilers (SysV Vax PCC?)) won't put "register short"s into registers. (Someday, someone should fix that....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
jgd@uwmcsd1.UUCP (John G Dobnick) (08/10/85)
>In any case, most experienced C programmers will use "short" when 16 >bits is known to suffice and "long" when 32 bits are needed. Um, excuse me folks, but this discussion is getting very machine dependent. Everyone seems to be assuming, at least tacitly, that "ints" come in only two sizes: 16 bits and 32 bits. I explicitly wish to point out that we run a UNIX implementation on a machine that uses the following: short int: 18 bits long int: 36 bits Said machine is a Sperry 1100. (Sperry used to be called Univac. Why they changed their name, I'll never know, but they did it on April 1st! Really!!) I smell a ra... er, um, a VAX/PDP/68K bias here. (:-)) -- -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee (...ihnp4!uwmcsd1!jgd)
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/11/85)
> >In any case, most experienced C programmers will use "short" when 16 > >bits is known to suffice and "long" when 32 bits are needed. > Um, excuse me folks, but this discussion is getting very machine dependent. > Everyone seems to be assuming, at least tacitly, that "ints" come in > only two sizes: 16 bits and 32 bits. Not at all. These are the minimum number of bits guaranteed in the ANSI spec.
guy@sun.uucp (Guy Harris) (08/11/85)
> I beg to differ: I tend to use "int" when 16 bits will suffice and > I'm not concerned with data space, and I think many others would do > the same, especially since the 4BSD Vax PCC compiler (and probably > many other compilers (SysV Vax PCC?)) won't put "register short"s > into registers. (Someday, someone should fix that....) Since "int" is supposed to be the "natural" size of integers on a particular machine, this is the correct thing to do when 16 bits is sufficient but more bits doesn't hurt (i.e., if data space isn't a problem or if the item is in a structure which isn't seen by other pieces of hardware). The S5 VAX PCC puts "register short"s into registers. The S3 VAX PCC did, also, but produced the "poor and sometimes incorrect" code that the 4.xBSD manual referred to; that's why Berkeley change the S3 VAX PCC not to put them into registers. I looked at a couple pieces of code from the S5 VAX PCC. It seemed to do some possibly-unnecessary work, but that may be due to the semantics of sub-longwordlength-arithmetic in C and on the VAX. (I don't know what the "poor and sometimes incorrect" code was, so I wasn't able to see if the S5 VAX PCC generated it or not.) Guy Harris
robert@gitpyr.UUCP (Robert Viduya) (08/13/85)
In article <384@uwmcsd1.UUCP>, jgd@uwmcsd1.UUCP (John G Dobnick) writes: > > Um, excuse me folks, but this discussion is getting very machine dependent. > Everyone seems to be assuming, at least tacitly, that "ints" come in > only two sizes: 16 bits and 32 bits. > > I explicitly wish to point out that we run a UNIX implementation on a > machine that uses the following: > > short int: 18 bits > long int: 36 bits > I'd like to further point out that one of the machines I have access to has the following: char: 8 bits short: 32 bits int: 64 bits long: 64 bits The machine (Control Data Cyber 180/855) doesn't support 16-bit arithmetic very well, which is why shorts aren't 16-bits, ints aren't 32 bits and longs aren't 64 bits. robert -- Robert Viduya 01111000 Georgia Institute of Technology UUCP: {akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert {rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert BITNET: CCOPRRV @ GITVM1
guy@sun.uucp (Guy Harris) (08/13/85)
> >In any case, most experienced C programmers will use "short" when 16 > >bits is known to suffice and "long" when 32 bits are needed. > > (Mention of Sperry 1100 C with 18-bit "short"s and 36-bit "long"s). In this case the above assumption is still reasonably good; what's two bits between friends? (Besides, what would $.25 buy you these days? :-)) 24-bit machines are trickier; 12 bits is too short for "short" (PDP-8 enthusiasts nonwithstanding) and 48 bits is a bit long for a "long". (Anybody know what the Harris (no relation) 24-bit/48-bit machines' C implementations use?) Guy Harris
peter@baylor.UUCP (Peter da Silva) (08/13/85)
> Said machine is a Sperry 1100. (Sperry used to be called Univac. Why they > changed their name, I'll never know, but they did it on April 1st! Really!!) > > I smell a ra... er, um, a VAX/PDP/68K bias here. (:-)) On a machine like that I would guess you would have many other portability problems as well. How big are chars, and what character set do you use? -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
jgd@uwmcsd1.UUCP (John G Dobnick) (08/14/85)
> > Said machine is a Sperry 1100. > On a machine like that I would guess you would have many other portability > problems as well. How big are chars, and what character set do you use? > -- > Peter da Silva (the mad Australian) > UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter > MCI: PDASILVA; CIS: 70216,1076 The character set is ASCII. The character size is 9 bits, packed 4 characters per word. With ASCII, this "wastes" 1 bit per character (assuming 8-bit characters). The major *problem* this causes is the following: you can not assume that two adjacent characters are equivalent to a "short" (16-bit?) integer. This is a portability problem, in that the Sperry implementation will have this "extra" bit between the characters. This is also bad programming practice. This has also bitten us in porting "VAX-ish" C code to the Sperry. End hardware exposition. -- I think koalas are *neat* animals, but they don't *do* very much! -- -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee (...ihnp4!uwmcsd1!jgd)
alan@rice.ARPA (08/15/85)
>I'd like to further point out that one of the machines I have access to has >the following: > > char: 8 bits > short: 32 bits > int: 64 bits > long: 64 bits > >The machine (Control Data Cyber 180/855) doesn't support 16-bit arithmetic >very well, which is why shorts aren't 16-bits, ints aren't 32 bits and longs >aren't 64 bits. > > robert >-- >Robert Viduya 01111000 >Georgia Institute of Technology Well, what is it? Are longs 64 bits are aren't they? Alan Painter alan@ots
doon@sdcrdcf.UUCP (Harry W. Reed) (08/15/85)
In article <2620@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> >In any case, most experienced C programmers will use "short" when 16 >> >bits is known to suffice and "long" when 32 bits are needed. >> >> (Mention of Sperry 1100 C with 18-bit "short"s and 36-bit "long"s). > >In this case the above assumption is still reasonably good; what's two bits >between friends? (Besides, what would $.25 buy you these days? :-)) 24-bit >machines are trickier; 12 bits is too short for "short" (PDP-8 enthusiasts >nonwithstanding) and 48 bits is a bit long for a "long". (Anybody know what >the Harris (no relation) 24-bit/48-bit machines' C implementations use?) > > Guy Harris Hi: The Harris H800 (etc) implementation of 'C' uses 24-bit integers. I've worked on a Harris for about 2 years and I must say that it has a VERY NASTY machine architecture. Gimme a VAX or a 32000 any day!!! Harry Reed
ron@brl-tgr.ARPA (Ron Natalie <ron>) (08/16/85)
> >I'd like to further point out that one of the machines I have access to has > >the following: > > > > char: 8 bits > > short: 32 bits > > int: 64 bits > > long: 64 bits > > > >The machine (Control Data Cyber 180/855) doesn't support 16-bit arithmetic > >very well, which is why shorts aren't 16-bits, ints aren't 32 bits and longs > >aren't 64 bits. > > > > robert When BRL did the C compiler for the Denelcor HEP, shorts are 16, ints and longs are 64 (the word size). The HEP can calculate just fine on 8, 16, 32, or 64 bit quantities. However, ints really need to be 64. This was solved by adding another integer type "medium" (actually, called _int32), which no one except the kernel hackers need to know about. -Ron I wanted to call them "short longs."
robert@gitpyr.UUCP (Robert Viduya) (08/17/85)
In article <719@brl-tgr.ARPA>, alan@rice.ARPA writes: > >I'd like to further point out that one of the machines I have access to has > >the following: > > > > char: 8 bits > > short: 32 bits > > int: 64 bits > > long: 64 bits > > > >The machine (Control Data Cyber 180/855) doesn't support 16-bit arithmetic > >very well, which is why shorts aren't 16-bits, ints aren't 32 bits and longs > >aren't 64 bits. > > Well, what is it? Are longs 64 bits are aren't they? > Oops... longs ARE 64 bits. I got slightly carried away. Sorry... -- Robert Viduya 01111000 Georgia Institute of Technology UUCP: {akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert {rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert BITNET: CCOPRRV @ GITVM1
tp@ndm20 (08/29/85)
>>nonwithstanding) and 48 bits is a bit long for a "long". (Anybody know what >>the Harris (no relation) 24-bit/48-bit machines' C implementations use?) >> >> Guy Harris >Hi: > The Harris H800 (etc) implementation of 'C' uses 24-bit integers. > > Harry Reed To be more complete, the Harris H-series uses 8 bit char, 24 bit short, 24 bit int, and 48 bit long. On top of everything else, the formats of char pointers are different from all other pointers, and word alignment is mandatory for everything but char, because the machine is (24 bit) word addressable. I work on a Harris 700. Their other 2 product lines, the Harris Station series (i.e. this machine) and the HCX-7 are 32 bit unix machines. Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA