🚀 go-pugleaf

> Path:
newsbf01.news.aol.com!newstf01.news.aol.com!news-e1a.megaweb.com!howland.r
eston.ans.net!gatech!news.sprintlink.net!dispatch.news.demon.net!demon!tank
.news.pipex.net!pipex!sunsite.doc.ic.ac.uk!hgmp.mrc.ac.uk!news.dcs.warwick.
ac.uk!not-for-mail
> From: A.Main@dcs.warwick.ac.uk (Zefram)
> ...
> Does anyone else think it's a really silly idea to only require
> compilers to accept extended ranges up to 128 bits?  (That's the
> requirement in the SBEIR paper.)  We're bound to run up against it
> sooner or later, causing problems (for strictly conforming code)
> analagous to the current 16-bit int / 32-bit long problem, though not
> nearly as bad.  Surely the implementation should be required to support
> types as large as system resources will allow?

This is a balance between what the compiler implementors want to provide
and what the users would like.  The reason for choosing 128 bits was
the IEEE 1596.5 specification which requires numbers up to 128 bits of
precision.  You're right in the sense that the minimum implementation
requirements are somewhat arbitrary.  Having another standard to point to
gives some, albeit weak, rationale for chosing that number.

Another feature of choosing a limit, rather than just the machine
resources, is that I will be able to write *strictly conforming*
applications (``assertion-oriented'' programming -- works the same on
all machines) rather than *conforming* applications (``inquiry-oriented''
--
works on some machines).  Furthermore, implementations might only allow
a maximum of 32 bits, which isn't any real improvement.

When speaking with implementors about SBEIR, they desire fast
implementations because their customers will demand them.  The
implementors are non-plussed about calling subroutines to perform
arithmetic.  With arbitrary precision arithmetic, they'd probably
have to do this by calling subroutines.  It's unlikely that a RISC
architecture would support abritrary precision arithmetic since this
isn't a common operation -- CISC architectures might support this.
As I read them, the implementors could deal with extending some of
the simpler operations (add, subtract, negate, shift, and, or, not,
etc.) by simple extensions to the code generator (e.g., add the low
order part, increment the high order part if the carry bit was set,
add the high order part).  The more complex operations (e.g., multiply,
divide, remainder) could be done by calling multi-precision libraries
(there are several publicly available libraries).  This separation of
code generation extensions for the simple stuff and libraries otherwise
was the method used on the PDP-11 and other machines (thus, tried and
true technology).

In summary, 128 bits seems like a reasonable minimum maxima but
arbritrary precision would meet much resistance.  Of course, I agree
that arbitrary precision would be useful.  However, we have to take
this step by step.  The SBEIR establishes the basics of solving the
integer range problem.  Maybe later we can look at extending the
implementation limits (just as C9X is now looking to extend the
implementation limits of C89).

-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