Absolute size of 'short'

[William E. Davidsen Jr]

In article <2970 at tekcrl.CRL.TEK.COM> danw at tekchips.CRL.TEK.COM (Daniel E. Wilson;1432;58-790;;) writes:
| > I proposed something like this to X3J11 in the first year or so (I was
| > only there two years). What I suggested was size in bytes, allowing:
| > 	int foo*4
| > 	-or-
| > 	int*4 foo;
| > The feeling was that it was (a) not really needed and (b) too much like
| > fortran. I like your idea better, but the few cases where you want exact
| > size rather than minimum size probably don't justify inclusion.
| 
|      I thought this was C not FORTRAN 77.  The reason why the size of an
| int is not tightly defined is so that the compiler will use the  
| best size for the computer.  Usually so the program will wind up being
| faster.  

  I think I should have quoted a bit of the previous posting. The intent
was to give the compiler all the information so it could choose the best
representation. Currently to get a four byte (or more) integer I say
long. dpANS says that this will be at least 32 bits. If I need four
bytes and short is 2, int is 4, and long is 8, I could say int*4 and get
the best data type which would hold the data. There was no intension of
forcing high overhead on any implemention, just giving the compiler more
information, like the register declaration.

  Consider some programs which need at least 48 bit integers. Currently
that information has to be carried in the documentation, so you know it
runs on a Cray, CDC, mini-super, etc. If I could say int*6 the compiler
on a smaller machine now has the option of generating an error "not on
this machine, you don't", or generating code which gives me the
precision I need, and hopefully a warning that it is being done in
software.

  I hate to say it, but 'noalias' didn't offent me a bit. It was a way
to let compilers generate better code, and I didn't have to learn or use
it if I chose not to. I believe in telling the compiler as much as I
can, because guesses are usually not optimal.

| > I would really like to see a "packed struct," also. 
| 
|     It would seem that a well written compiler would already choose the
| best alignments of members in a structure.  Also remember that some
| types of hardware can't address a word on a byte boundry (PDP-11) and
| so this option would end up not being implemented.  A good 80x86 compiler
| would probably not pad a structure because the hardware doesn't care how
| an int is aligned.

  The problem here is that you and I may disagree about "best
alignment". If I need best speed then the compiler probably does that.
If I need to get the absolute smallest packing of data, then I can use
the 'packed struct' concept.

  Good compilers for the 80x86 do pack structures, because it makes
things run faster. The 80286 takes one (or two) additional clocks to
fetch unaligned, as does the 80386 if not aligned mod four. I believe
the same is true on the 68k series, but my hardware manual isn't handy.
It's a tradeoff between space and speed.

  The Microsoft C compilers allow the user to comtrol the packing.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me