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.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!vrdxhq!deller From: deller@vrdxhq.UUCP Newsgroups: comp.lang.ada Subject: Re: language problem Message-ID: <3322@vrdxhq.UUCP> Date: Thu, 2-Apr-87 19:52:21 EST Article-I.D.: vrdxhq.3322 Posted: Thu Apr 2 19:52:21 1987 Date-Received: Sat, 4-Apr-87 18:31:10 EST References: Organization: Verdix Corporation, Chantilly, VA Summary: Original posting correct, followup posting incorrect List-Id: In article , ms8k#@andrew.cmu.edu (Marc Scheurer) writes: > > Verdix Ada v1.5 is completely bogus. Don't be amazed by problems like this. > Another example is ... (and other comments about Verdix Ada 1.5 [sic]) The full original posting follows below in case there is any doubt about the context of this reply, and is followed by code and compilation/execution outputs that illustrate correct handling of bit and size representations by VADS 5.41. I apologize for this lengthy reply; accuracy demands it. Verdix has never had a v1.5 compiler. I presume Marc is referring to VADS 5.1a, which states explicitely in its documentation that bit representations and size representations are NOT supported with that version. The fatal diagnostics that say "type is too small" occurred naturally because of that lack of support. We were adding support with the next version, so we did not feel the need to add a special diagnostic to say "not supported yet". VADS 5.41 has full support for the features Marc complains about, except on two of the machines in our product line (CCI and Sequent). The documentation clearly states whether a release supports those features or not. Sequent (and other 32032 products) will have bit rep support with the next VADS release. VADS 5.1a, used by Marc, was last shipped around April 1986. VADS 5.41 began shipping in January 1987, in stages across all products: Sun, VAX/VMS, VAX/UNIX-ULTRIX, Sequent, Apollo, Masscomp, CCI, 68K crosses, 1750a crosses, and others. 5.41 sources with bit and size representation support have been shipped to all of our source customers (well over 20 computers). As for the original problem mentioned of a constraint error being missed in an array operation, the Verdix 5.41 compiler does indeed fail to raise a constraint error as required by the RM (the code produces the correct "enumerical" :-) result, and only fails to raise the constraint error). Note that raising a constraint error is not a sufficient test of correct execution of the statements presented. Robert Dewar has given an excellent presentation at a SIGAda conference illustrating the problems with this apparently simple construct. If I remember correctly (any errors are mine, not his) the primary problem with the assignment is that it must be atomic, either performed for EVERY array element, or not performed for ANY array element. The code generated must ensure, at the point it detects any result with a constraint error, that all elements are either assigned to by the assignment, or that the elements assigned to so far are "backed out". Efficiency concerns preclude the easy out of using an intermediate temporary array and copying it to the result array if there are no constraint errors. I believe that this code generation complication is part of the reason for the VADS compiler missed the constraint error. The example is clearly a pathological test. A type derived from a boolean but constrained to a single value, yet not a constant, does not appear to be very useful. VADS is built to operate efficiently on types normally encountered in practice, and works well in those cases. Clearly, however, there is an error in VADS 5.41 for this case, which requires a "more proper" solution within the compiler to provide both the efficiency desired and the correctness required by the RM. As a test of the boundary conditions for our code generation with array operations, the original code serves very well. We would like to thank Amiram for providing this test. This error will be fixed in the next release of VADS. As for VADS being "bogus", Marc is mistaken. He is apparently operating with a very old VADS version that explicitly did not support the implementation dependent features he is interested in. That compiler was validated, with the noted limitations in implementation dependent features. VADS 5.41 is validated under the latest validation suite available at this time. Our best identification of his site is a site that chose not to pay for maintenance for the system and product he is using. Sites that have paid maintenance fees (including many sites within his apparent organization) are now receiving VADS 5.41 shipments with full support for bit and size representations specifications. Why a site might choose not to purchase maintenance is their business, but that decision should not then be a reason to spuriously castigate Verdix in such a wide forum as Usenet. The original posting and code example follow. Feel free to hit your "n" key at this point (if you made it this far) :-). Steven Deller Director, Verdix Product Support Original posting, in toto: In article , ms8k#@andrew.cmu.edu (Marc Scheurer) writes: > In article <8703261730.AA28726@taurus> amiram@TAURUS.BITNET.UUCP writes: > >A colleague of mine, Yossi Veler of AITECH has come up with the following > >program in Ada, which seems to create a serious problem. > > > >procedure boolsub is > > subtype bool is boolean range true..true; > > type arr is array(1..10) of bool; > > a : arr := (1..10 => true); -- this seems like the only legal value > >begin > > a := not a; > >-- Here a(1)=a(2)=...=a(10)= FALSE !!!! No exception occurs etc. > > a := (1..10 => false); > >-- This does cause an exception > >end boolsub; > > > >The program seems legal : we inspected the LRM and also the implementers > >guide, and we ran it on both the DDC and VERDIX compilers. It seems that > >a combination of innocent features in Ada produces a result that seems to > >contradict with the basic philosophy of the language, that is an object > >posseses a value which is not in the appropriate type. > > Verdix Ada v1.5 is completely bogus. Don't be amazed by problems like this. > Another example is > > type BYTE is range 0 .. 255; > for BYTE'SIZE use 8; > > Verdix compiler says that the size is too small. > > type BYTE is new POSITIVE range 0 .. 255; > for BYTE'SIZE use 8; > > same thing! 0 as a POSITIVE does not disturb it. The bit sign is still there. > > type BYTE is range -128 .. 127 > for BYTE'SIZE use 8; > > is ok (at last), but is not really what was wanted. Another solution may be > an enumaration of 256 items, a little painful. > > ____________________________________________________________ > Marc A. Scheurer > > Arpanet, Bitnet: ms8k@andrew.cmu.edu > UUCP : seismo!andrew.cmu.edu!ms8k > ____________________________________________________________ P.P.S. (For die hard Ada code readers :-) ). The following program and outputs (separated by lines of +++) illustrate correct handling of size representations by the Verdix VADS 5.41 compiler that is currently shipping for Sun-3 systems. Please note the VADS diagnostic for PBYTE, a type originally cited as not being handled correctly by VADS -- that type specification is erroneous Ada as the Marc noted (POSITIVE does not include zero), so I have commented out the offending lines (and left the diagnostics in). I added NBYTE, which uses NATURAL and does include zero. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ size.a with UNCHECKED_CONVERSION ; with TEXT_IO ; use TEXT_IO ; procedure size is type UBYTE is range 0 .. 255; for UBYTE'SIZE use 8; --type PBYTE is new POSITIVE range 0 .. 255; -------------------------------------^A ### --### A:warning: bounds check will raise CONSTRAINT_ERROR at runtime --for PBYTE'SIZE use 8; type NBYTE is new NATURAL range 0 .. 255; for NBYTE'SIZE use 8; type SBYTE is range -128 .. 127; for SBYTE'SIZE use 8; package UB_IO is new INTEGER_IO( UBYTE ) ; package SB_IO is new INTEGER_IO( SBYTE ) ; function TO_UNSIGNED is new UNCHECKED_CONVERSION( SBYTE, UBYTE ) ; NB : NBYTE ; SB : SBYTE ; UB : UBYTE ; begin NB := 255 ; NB := 0 ; SB := 127 ; PUT( "Unsigned conversion of 127 = " ) ; UB_IO.PUT( TO_UNSIGNED(SB) ) ; NEW_LINE ; SB := -128 ; UB := TO_UNSIGNED(SB) ; PUT( "Unsigned conversion of -128 = " ) ; UB_IO.PUT( UB ) ; NEW_LINE ; PUT( "Unsigned conversion of -1 = " ) ; UB_IO.PUT( TO_UNSIGNED(-1) ) ; NEW_LINE ; loop PUT( "Enter value -128..127: " ) ; SB_IO.GET( SB ) ; PUT( "which is a value of " ) ; UB_IO.PUT( TO_UNSIGNED(SB) ) ; PUT_LINE( " unsigned" ) ; exit when SB = 0 ; end loop ; end ; ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ compile results ========================================= Verdix Ada Compiler, Copyright 1984, 1985, 1986 Version 5.41 - Sun 3 Unix Fri Jan 23 15:06:21 PST 1987 (p) File: /vc/deller/x/size.a compiled Thu Apr 2 07:41:41 1987 by user deller unit: subprogram body size NO Ada ERRORS UNIT ENTERED 37 statements 51 lines TIMES for Front End wall 11.52 cpu 3.80 TIMES for Code Generator wall 2.80 cpu 1.33 TIMES for TOTAL TIME wall 15.24 cpu 5.56 ========================================= Verdix Ada Compiler, Copyright 1984, 1985, 1986 Version 5.41 - Sun 3 Unix Fri Jan 23 15:06:21 PST 1987 (p) TIMES for a.ld wall 34.42 cpu 12.30 TIMES for TOTAL TIME wall 35.14 cpu 12.58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ execution results Script started on Thu Apr 2 07:47:53 1987 ... (elided "junk") gilligan% size.out Unsigned conversion of 127 = 127 Unsigned conversion of -128 = 128 Unsigned conversion of -1 = 255 Enter value -128..127: -127 which is a value of 129 unsigned Enter value -128..127: -126 which is a value of 130 unsigned Enter value -128..127: -10 which is a value of 246 unsigned Enter value -128..127: -5 which is a value of 251 unsigned Enter value -128..127: -3 which is a value of 253 unsigned Enter value -128..127: -2 which is a value of 254 unsigned Enter value -128..127: 1 which is a value of 1 unsigned Enter value -128..127: 2 which is a value of 2 unsigned Enter value -128..127: 3 which is a value of 3 unsigned Enter value -128..127: 126 which is a value of 126 unsigned Enter value -128..127: 0 which is a value of 0 unsigned gilligan% exit ... (elided "junk") script done on Thu Apr 2 07:49:09 1987 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ done -- ::= | | | {verdix,seismo,umcp-cs}!vrdxhq!deller