Re: language problem

[deller@vrdxhq.UUCP]

In article <MS.V3.18.ms8k.80021103.harrisburg.ibm032.535.0@andrew.cmu.edu>, 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 <MS.V3.18.ms8k.80021103.harrisburg.ibm032.535.0@andrew.cmu.edu>, 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
-- 
<end_message> ::= <disclaimer> | <joke> | <witty_saying> | <cute_graphic>
{verdix,seismo,umcp-cs}!vrdxhq!deller