From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,885dab3998d28a4
X-Google-Attributes: gid103376,public
From: mfb@mbunix.mitre.org (Michael F Brenner)
Subject: Re: Ariane 5 failure
Date: 1996/10/16
Message-ID: <542r7r$ema@linus.mitre.org>#1/1
X-Deja-AN: 189828296
references: <96101416363982@psavax.pwfl.com>
 <EACHUS.96Oct15152359@spectre.mitre.org> <dewar.845420361@merv>
organization: The MITRE Corporation, Bedford Mass.
newsgroups: comp.lang.ada
Date: 1996-10-16T00:00:00+00:00
List-Id: <comp.lang.ada>


. Dewar said:

    > I think that saturating types
    > would be overkill in terms of predefined integral types. Adding new classes
    > of integral types adds a lot of stuff to the language, just look at all the
    > stuff for supporting modular types.
    >
    > I think a much more reasonable approach for saturating operators is to
    > define the necessary operators. If you need some very clever efficient
    > code for these operators, then either use inlined machine code, or persuade
    > your vendor to implement these as efficient intrinsics, that is always
    > allowed.

This hops on both sides of the horse at the same time. It was good to add
modular types into Ada-95, but it was bad to add a lot of stuff to the language.
It was an unnecessary management decision, not related to the technical
requirement for efficient modular types, to add anything to the language
Other Than clever, efficient, reliable code for modular operators. A different
management decision would have been to keep the way all Ada 83 compilers
with modular types did it, leaving them Represented as ordinary integers,
but overloading an alternate set of arithemetic operators over those ordinary
integers, so that conversion between twoUs complement and modular binary
would not require any code to be generated (except a possibly optimized
away copy of the integer). This would still permit inefficient BCD
implementations of modular arithmetic wherever the efficient hardware
operators are not available on a given target architecture. 

Had this alternate decision been made, then R. DewarUs second half of the
comment could have been focussed on with more energy, namely, how can
more efficient code be generated for several different kinds of operators. 
Solutions sometimes available are interfacing to assembler language and
inline machine code. Solutions available to those with larger than normal
amounts of funding include paying a compiler maintainer to implement 
and efficient intrinsic function. But Another Way, for future consideration,
is to permit users to implement attributes or efficient intrinsic functions
by permitting pragmas which Demand certain performance requirements
of the generated code. As Dr. Dewar has repeatedly pointed out, performance
requirements are currently beyond the scope of the language definition. 
However, many programs have performance requirements, and having
a way to specify them (in an Appendix) would not detract from the 
language, but make it more useful in the realtime world. Examples of
such specifications include: (1) the topic of this thread (saturating overflows),
(2) do not generate code for a given instantiation of unchecked_conversion,
(3) do not even generate a copy for invocations of a given instantiation
of unchecked_conversion, (4) permit modular operations on an ordinary
user-defined range type, (5) use a particular run-time routine to implement
a particular array slice or Others initialization, (6) use a particular
machine code instruction to implement a particular array slice or Others
initialization, (7) truly deallocate a variable now, (8) truly deallocate
all variables of a given subtype now, (9) permit the use of all bits in 
the word in a given fixed-point arithmetic type, etc.
.
ZZ