🚀 go-pugleaf

(Sorry if this got posted twice.)

> From: thads@csn.net (Thad Smith)
> 
> I haven't seen IEEE 1596.5, but have to wonder what the uses of
> integers beyond 40 bits or so is.  The primary point of integers is to
> count.  When do you need to count beyond 2 to the 40th?  2 to the
> 64th?
> 
> Other conceivable uses are for high-resolution fixed point arithmetic
> (why not use floating point?), structures holding several fields (why
> not declare these as actual structures?) and number theory, as used in
> RSA computing (you need more precision anyway for this application).

The use of large integers doesn't mean we need to count that high.  If
that were the case, mathematics would be confined to small numbers.  A
couple every day examples from computing would be a 64-bit timestamp
(high order is number of seconds, low order is fractions down to about
250 picoseconds) or a 64-bit fat pointer (high order is IP address, low
order is local memory address).  Since there are about 10^80 particles
in the universe, we'd need approximately 256 bits to itemize them (this
would take a long while :-).  You might say 256 bits is a reasonable limit
based on this.  But then there are very large numbers used for crypto
work, so we might need more.

The IEEE 1596.5 standard specifies (in C terminology) arithmetic data
types, semantics, layout, alignment, representation, and access methods.
The full title is ``IEEE Standard for Shared-Data Formats Optimized for
Scalable Coherent Interface (SCI) Processors''.  The following is the
abstract:

	Formats for interchanging integer, bit-field, and floating-point
	data between heterogeneous multiprocessors in a Scalable Coherent
	Interface (SCI) system are specified.  The standards that support
	the read, write, and lock transaction set defined by IEEE Std
	1212-1991 CSR Architecture.  The intent is to support efficient
	data transfers among heterogeneous workstations within a
	distributed compuing environment.

The IEEE standard defines such (sample) data types as:

	IntegerQuadmin
	UnalignedLittleSignedOctlet
	AlignedBigUnsignedHexlet

Where:

	- alignment is native, unaligned (byte alignment), aligned
(multiple
	of data type size)
	- ordering is native, big endian, little endian, or custom (IBM,
	DEC, and Cray floating point formats)
	- signedness is signed or unsigned
	- precision is 8, 16, 32, 64, or 128 bits
	- exactness is atleast or exact

The types above would be bound to the following SBEIR, OAX (ordering
and alignment extensions), and REP (representation) features:

	/*
	 * IntegerQuadmin
	 * alignment: native, ordering: native, signedness: signed,
	 * precision: 32, exactness: at-least
	 */
	typedef signed int atleast:32
		IntegerQuadmin;

	/*
	 * UnalignedLittleSignedOctlet
	 * alignment: 1, ordering: little endian, signedness: signed,
	 * precision: 64, exactness: exact
	 */
	typedef signed int exact:64 align:1 order:OAX_LITTLE
		UnalignedLittleSignedOctlet;

	/*
	 * AlignedBigUnsignedHexlet
	 * alginment: 16, ordering: big endian, signedness: unsigned,
	 * precision: 128, exactness: exact
	 */
	typedef unsigned int exact:128 align:16 order:OAX_BIG
		AlignedBigUnsignedHexlet;

The access methods of these types cover reading (read1, read2, ...,
read16), writing (write1, write2, ..., write16), make and swap (maksSwap4,
maskSwap8), compare and swap (compareSwap4, compareSwap8), fetch and
add (bigAdd4, bigAdd8, littleAdd4, littleAdd8).  The access methods are
outside the scope of SBEIR, OAX, and REP.

The IEEE 1596.5 standard addresses some, but not all of the problems
addressed by SBEIR.  This is because IEEE 1596.5 is primarily used for
data interchange (agreeing on precision, layout, etc., is more important
than performance issue) whereas SBEIR is used for processing (concerns
precision, exactness, and performance).  The combination of SBEIR, OAX,
and REP give most of the features of IEEE 1596.5 (i.e., data layout, but
not access methods for "volatile" types).  With this combination, it is
possible to bind the IEEE 1596.5 types to SBEIR/OAX/REP types.

-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