🚀 go-pugleaf

> From: A.Main@dcs.warwick.ac.uk (Zefram)
> 
> I think it's rather misleading to refer to what I propose as "arbitrary
> precision", but not the current SBEIR proposal.  On a 16-bit machine,
> 128 bits is eight words, arithmetic with which isn't going to be
> inlined unrolled as a matter of course.  128 bits may well be a
> sensible minimum maximum at the moment, but I don't think it's
> unreasonable to expect implementations to handle any fixed (at
> compile-time) size integral type that can be reasonably manipulated on
> the hardware in question.

Hmmm.  Maybe I've misunderstood you.  I thought you were proposing that
the precision would be limited by the machine resources, i.e., I could
have a 1024-bit number if there were enough memory available (of course,
we are all talking about *compile-time* determination of precision,
not determining the precision of a type at *run-time*).  You could
make the claim that code generators could always unwind code OR they
could always call subroutines to perform the arithmetic.  Where you
draw the line between these two extremes is determined by your machine
architecture.  As I've said before there isn't a strong rationale for
128 bits (compared to any other number), but we do have to specify some
minimum maxima.  As I read the competing interests in WG14, there are
those (implementors, of course) that want the number as small as
possible and others (e.g., users) that want the number as large as
possible (possibly unlimited).  The following is my reading of possible
values:

	32 bits: Not useful - we already have this now in C.

	64 bits: Minimally useful because it satisfies a need for
	having a 64-bit type.  This is not enough for the 128-bit
	types of IEEE 1596.5.

	96 bits: An oddball number (people would want 64 or 128, not
	96).  This is not enough for the 128-bit types of IEEE 1596.5.

	128 bits: Acceptable for IEEE 1596.5.  Good (probably) for the
	next 10 years as 128-bit machines become available.  There is
	some grumbling from implementors emulating this arithmetic on
	their machines.

	256 bits: There aren't a whole lot of applications or users
	screaming for this.  This would be a burden on implementors
	for a feature that would hardly be used.

	>256 bits: About the only reason for larger precision might be
	handling 307 digit RSA keys (about 1020 bits of arithmetic)
	in PGP security.  Again, users haven't been screaming for this.

	Arbitrary precision: There isn't a minimum maxima, so this
	would revert to 32 bits for strictly conforming applications --
	not useful.

Since the minimum maxima is a separable issue, I'd expect that we will
revisit this many times in C9X.  We really need to hear all sides on
this issue (vendors, test suites, users, etc.) to make an informed
decision.  I will be collecting this information to include in the SBEIR
rationale.  If you'd like to propose a specific minimum maxima, send me
E-mail at "frank@farance.com" with your suggestion and its rationale
(don't just send a number without rationale).  Thanx in advance for your
input.

-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