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=0.7 required=5.0 tests=BAYES_00,FROM_ADDR_WS,
	INVALID_DATE,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,72d0d0a56877b2ed
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-10-05 02:25:04 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!usc!news.cerf.net!hacgate2.hac.com!mass.rsg.hac.com!F22ELLIS
From: f22ellis@mass.rsg.hac.com (Mike Ellis.......(310) 334-1652)
Newsgroups: comp.lang.ada
Subject: Re: Ada83 or DEC Ada: Feature or bug?
Date: 5 Oct 1994 07:59:24 GMT
Organization: Hughes Aerospace & Electronics Co.
Message-ID: <36tmcs$7sh@hacgate2.hac.com>
References: 
 <360ecv$kq1@hacker.demon.co.uk>,<CwrGBu.CJr@lazrus.cca.rockwell.com>
Reply-To: f22ellis@mass.rsg.hac.com
NNTP-Posting-Host: atom45.es.hac.com
Date: 1994-10-05T07:59:24+00:00
List-Id: <comp.lang.ada>

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.