🚀 go-pugleaf

> From: mitch@manta.nosc.mil (Ray Mitchell)
> 
> Please excuse this posting if the subject has already been addressed.
> I just started following the discussion regarding "long long" etc. and
have
> noticed several references to 8/16/32/64/128... bit types.  Has
something
> in the standard changed to require everything be based on 8 bits or is
this
> a quick and dirty way of representing any machine such as when the types
are
> 9/18/36/72/144... or some other lengths based upon bytes which are not 8
bits?

I believe most of the discussion has revolved around multiple-of-8
architectures, but the SBEIR proposal is not tied to these architectures.
See the proposal in:

	ftp://ftp.dmk.com/DMK/sc22wg14/c9x/extended-integers/sbeir.*

There was some discussion previously about 36-bit machines and 24-bit
machines.

The discussion of 64, 128, 256, and 1024 bits was about what
is the minimum precision the Standard should require for the SBEIR
types?  Currently, the Standard requires 32 bits for "long".  On 36-bit
machines this might be implemented as a 36-bit number (or possibly a
72-bit number).

The discussion of 32-bit vs. 64-bit "long" is about what is the
``correct''
mapping (there is no singularly correct mapping) on certain 32-bit and
64-bit architectures.  The SBEIR proposal doesn't recommend specific
mappings, but requires the implementation to map (describe) the C types
into SBEIR types and maintain the following requirements:

	1.  The ordering char <= short <= int <= long is true.

	2.  The precisions are at least least the minimums
	required by the Standard (char: 8, short: 16, int: 16,
	long: 32).

-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: frank@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor