Absolute size of 'short'

[T. William Wells]

In article <11941 at steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) writes:
:   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.

That might be a good idea: allow an [unsigned] int*size (which
should be in bits since the standard defines things in terms of
bits) which, if the size is greater than 32 bits, is ...?  The
`...' is there because the current standard does not define a
class of behavior which permits the compiler to fail to translate
a correct program construct.

The best way to get this is for some compiler writers to put it
into their compiler.  If the extension proves popular, when it
comes time to revise the standard, it no doubt will get added to
the standard.

:   Good compilers for the 80x86 do pack structures, because it makes
				    ^pad?

: 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 68000 actually has real alignment restrictions.  Odd accesses
for integers can cause a fault.  I think later processors in the
series relax the restriction but are still slower for some
unaligned accesses.


---
Bill
novavax!proxftl!bill