Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available

[eachus@dr_no.mitre.org (Robert I. Eachus)]

    Summary:

    The ADAR packages are a portable langauge extension in an area
where Ada just isn't very portable.  We came up with a LOT of magic to
make this code possible, since when we started it was expected that
any Ada 83 decimal extension would require support by compiler
vendors.  The ADAR packages as produced have portable, but in some
cases slow, bodies which can be customized to a particular compiler to
get a very efficent facility.  But don't expect to do such
customization without knowing the compiler internals and the hardware
arithmetic model a lot better than you would like to.


In article <1993Mar22.223336.23771@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:

  > Ahem.  Actually, it's a shortcoming of the package that it depends
  > on Long_Integer....

  > If you want the longest possible integer type (whatever its name
  > happens to be in Standard), use something like this:

  >    type Longest_Integer is range System.Min_Int .. System.Max_Int;

  FLAME ON!!!!

    This sort of abstract pontificating has its place, but in this
case you do a significant disservice in posting something like this
without looking at the actual packages.

    First, most of the use of system dependant types occurs either in
a configuration package or in examples.

    Second, every such case is commented with WHY the decision to
declare things that way was made.

    Third, there are cases where declarations like Longest_Integer
above will simply not work, because you must use Standard.Integer.
Two examples are the rules in 3.6.1(2) and the exponentiation
operators defined in 4.5.6(4).

    Forth, well you get the picture...

  FLAME OFF.

    We went to a lot of work to push Ada to the edges of the Reference
Manual definition in the ADAR packages.  Unfortunately you can only
carry portability so far.  In general, the (package) specifications
are perfectly portable.  However, it is simply not possible to write,
for example, an efficient portable double precision multiply that will
work on 24-bit and 32-bit hardware.  Plan to change a couple of
constants.  (And don't flame me about the fact that you need static
values in some places that can't be calculated from static attributes.
Where they can, we did, but for example, find the largest power of ten
smaller than Integer'LAST in static Ada...)  We tried to produce
software which could be easily ported without modifying compilers.
But to expect the kind of magic which has to go on in the bodies of
these packages to port with zero effort, give me a BREAK.

    As a "simple" example, one of the implementations uses floating
point to provide a type with exact fixed-point semantics.  It works,
it's neat, but the number of digits for which you get exact decimal
arithmetic will be a complex function of the hardware floating point
model.  (It's usually 15 or 16.)  The code as written will get the
bounds right on most hardware I know of, but it does take some
attention to make sure.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...