Ada83 or DEC Ada: Feature or bug?

Ada83 or DEC Ada: Feature or bug?

[Stephen M. Youndt]

Is it a feature of Ada83 or DEC Ada that makes it impossible to work with
unsigned values? MAX_INT always bites back with CONSTRAINT_ERROR when I try
to do any real work with unsigned 32bit values (i.e. SYSTEM.UNSIGNED_LONGWORD).
Both I and my coworkers find this terribly annoying. Is this part of Ada83
or a DEC Ada peculiarity? If Ada83, will it be fixed in 9X?

Thanks,
Steve
-- 
Stephen M. Youndt   * Inet: steve@hacker.demon.co.uk  * CIS: 73121,3407
                    *     Tel: +44 242 863 028        *

Re: Ada83 or DEC Ada: Feature or bug?

[Tucker Taft]

In article <360ecv$kq1@hacker.demon.co.uk>,
Stephen M. Youndt <steve@hacker.demon.co.uk> wrote:

>Is it a feature of Ada83 or DEC Ada that makes it impossible to work with
>unsigned values? MAX_INT always bites back with CONSTRAINT_ERROR when I try
>to do any real work with unsigned 32bit values (i.e. SYSTEM.UNSIGNED_LONGWORD).
>Both I and my coworkers find this terribly annoying. Is this part of Ada83
>or a DEC Ada peculiarity? 

Ada 83 only provided for signed integers.  However, many Ada 83 
vendors have provided special packages to circumvent this problem.  
Apparently DEC did not go all the way in supporting them.

> ... If Ada83, will it be fixed in 9X?

In Ada 9X, there are unsigned integers, called "modular integers,"
which allow the user to specify the wrap-around point.  To get
a 32-bit unsigned integer, you would declare it as:

   type Unsigned_32 is mod 2**32;

> ...
>Stephen M. Youndt   * Inet: steve@hacker.demon.co.uk  * CIS: 73121,3407
>                    *     Tel: +44 242 863 028        *

S. Tucker Taft  stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA 02138

Re: Ada83 or DEC Ada: Feature or bug?

[Robert Dewar]

In Ada 83, you declare an unsigned value like this:

   type x is range 0 .. 2**32 - 1;

whether your compiler accepts this or not is up to the implementation (trying
to use this on many compilers won't work, but that's not a feature of Ada 83,
merely a (nasty) shortcoming of the implementation).

Note that you won't get wrap around arithmetic with this type, if you want
wrap around arithmetic, then you have to program it, or also check with
your implementor to see if they provide support for unsigned types (both
Dec and Alsys provide some support in separate packages -- other vendors
may too).

If your compiler rejects the above declaration, and if your vendor does not
provide any support for unsigned arithmetic in separate packages you are
out of luck. This is the same situation as the guy who wanted 64-bit signe
arithmetic maybe being out of luck if his compiler did not support it.

Trying to use 32-bit signed for 32-bit unsigned is very unlikely to be
satisfactory. Suppressing checks may work, but many compilers don't do
all possible suppression (it's not required), and you are then writing
erroneous programs which may or may not work.

Note that Ada 94 has mcuh better support for unsigned. Any reasonable
Ada 84 compiler will provide support for 32-bit unsigned arithmetic in
a convenient form:

   type unsigned is mod 2 ** 32;


as you might guess from this declaration, the arithmetic is the normal
wrap around (2's complement representation) unsigned arithmetic.

Re: Ada83 or DEC Ada: Feature or bug?

[Wayne Magor]

In article <360ecv$kq1@hacker.demon.co.uk>, steve@hacker.demon.co.uk (Stephen M. Youndt) writes:
>
>Is it a feature of Ada83 or DEC Ada that makes it impossible to work with
>unsigned values? MAX_INT always bites back with CONSTRAINT_ERROR when I try
>to do any real work with unsigned 32bit values (i.e. SYSTEM.UNSIGNED_LONGWORD).
>Both I and my coworkers find this terribly annoying. Is this part of Ada83
>or a DEC Ada peculiarity? If Ada83, will it be fixed in 9X?

This was a problem with Ada83 which is fixed in Ada-9X.  DEC defined
System.Unsigned_Longword like this:

   type UNSIGNED_LONGWORD is range -2_147_483_648 .. 2_147_483_647;
   for  UNSIGNED_LONGWORD'SIZE use 32;

whereas they defined System.Unsigned_Word like this:

   type UNSIGNED_WORD is range 0 .. 65535;
   for  UNSIGNED_WORD'SIZE use 16;

You can't really use Unsigned_Longword for much of anything except to
interface to other routines.

Wayne.

Re: Ada83 or DEC Ada: Feature or bug?

[Bevin R. Brett]

If there was ONE decision in DEC Ada V1.0 that I would get a chance to undo, it 
would be the silly way we did UNSIGNED_* and especially UNSIGNED_LONG.

We have had more grief from this than any other 'feature'.  But we can't
change it because that would be an upperwards-incompatible change, and our
commitment to our existing customers negates our desire to fix it for our
new ones,.

/Bevin

Re: Ada83 or DEC Ada: Feature or bug?

[Mike Ellis.......(310) 334-1652]

In article <CwrGBu.CJr@lazrus.cca.rockwell.com>, wemagor@fms0.cca.rockwell.com (Wayne Magor) writes:
>In article <360ecv$kq1@hacker.demon.co.uk>, steve@hacker.demon.co.uk (Stephen M. Youndt) writes:
>>Is it a feature of Ada83 or DEC Ada that makes it impossible to work with
>>unsigned values? MAX_INT always bites back with CONSTRAINT_ERROR when I try
>>to do any real work with unsigned 32bit values (i.e. SYSTEM.UNSIGNED_LONGWORD).
>>Both I and my coworkers find this terribly annoying. Is this part of Ada83
>>or a DEC Ada peculiarity? If Ada83, will it be fixed in 9X?
>
>This was a problem with Ada83 which is fixed in Ada-9X.  DEC defined
>System.Unsigned_Longword like this:
>
>   type UNSIGNED_LONGWORD is range -2_147_483_648 .. 2_147_483_647;
>   for  UNSIGNED_LONGWORD'SIZE use 32;

   According to DEC's Ada developers, the relevant language clauses are
   3.5.4 (7) "The range of each of these types must be symmetric about
   zero, excepting a possible extra negative value which may exist in some
   implementations."  All integer type declarations must follow 3.5.4 (6),
   and be derived from a predefined type, and hence must be symmetric. This
   means that to support 0..16#FFFF_FFFF# one would have to support at
   least 33 bit integers, probably 64, which in turn would radical impact
   on the compiler itself, the descriptors used to pass parameters, the
   runtime support, etc.

   This would be valid iff it were not for the fact that the deffinition
   appears in the *PACKAGE SYSTEM*.  This clause applies to "The predefined
   integer types..."  The type in question (UNSIGNED_LONGWORD) is provided
   via the SYSTEM package and need not be implemented as any particular
   type.  Language clause 13.7 (1) states that "The specification of the
   package SYSTEM is implementation-dependent...".  Appendix F which
   documents the DEC Ada implementation of the package system further
   states "This appendix is not part of the standard definition of the Ada
   programming language."  An example of this may be found in the
   implentation of the type SYSTEM.ADDRESS which is private and hence its
   implementation is not visible to the Ada programmer.  While simple math
   opperations involving a mixture of the type ADDRESS and the type INTEGER
   have been defined, there is nothing which defines the type ADDRESS to be
   a subtype of the INTEGER class.

   The "DEC Ada Run-Time Reference Manual" discusses the implementation of
   system.unsigned_longword in section 9.3.2 in the V3.0 manual.

   It would not be so bad if the *PARSER* could handle a 32 bit unsigned
   number.  One could easily write routines in MACRO (or any other language
   for that matter) to perform opperations on the 32 bit qunatities and do
   a pragma Interface.  Since the compiler won't let one specify a number
   of value greater than 31 bits (e.g. 16#FFFF_FFFF#) without resorting to
   tactics such as the use of overlays or negative numbers, there is not a
   clean, efficient way to deal with this limitation.  If performance is
   not an issue, one could always use bit arrays and re-invent addition,
   subtraction, multiplication, etc.  Another way to deal with the math
   part of the problem would be to provide an exception handler, do the
   math normaly and then deal with the exceptions on a bit array or simular
   basis.
                                                      ME
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

   F22Ellis@Radium.Hac.Com	M. D. to patient:  First the good news --
				you're going to have a disease named after you.