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,df854b5838c3e14
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Gripe about Ada, rep specs that won't.
Date: 1996/03/23
Message-ID: <dewar.827622165@schonberg>#1/1
X-Deja-AN: 143951581
references: <00001a73+00002504@msn.com> <Don8H5.AKI@world.std.com>
 <4iv0g6$6cs@news4.digex.net> <dewar.827534528@schonberg>
 <Doqp85.qn@world.std.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-03-23T00:00:00+00:00
List-Id: <comp.lang.ada>

Bob Duff said

"Ada *claims* to support representation clauses, which map nice
high-level data stuctures onto low-level hardware.  But it doesn't
always work.  It doesn't work when you have a single logical field split
across two separate physical fields (as in the segment tables on a 386,
where the segment size is split in two"

Ada does claim to support rep clauses that, in the words of the Ada 83
RM, words that were unwisely (in my opinion) delted rom the Ada 95 RM,
are "handled simply by the underlying hardware."

This is of course a subjective criterion, but certainly I do not regard
the discontiguous fields of the 386 segment table to be an example of
something that is handled simply. In machine language you load each
field separately and then combine them, and it seems perfectly reasoable
that you do that in Ada as well, explicitly creating an additinoal layer
of abstraction to load and store the field as a whole.

Similarly, typical hardware can support 4-bit packed fields, but not
9-bit packed fields, simply, so that's the support that is required.

Note: the reason I don't like the change in Ada 95 is that, although the
old standard was subjective, the attempt to enumerate the cases that are
considered simple and therefore required, which is what is done in the
Ada 95 RM, leaves a VERY weak minimum subset required. The result is that
there can be rep clauses which everyone would agree can be "handled
simply by the underlying hardware", but the Ada 95 RM explicitly says
that they need not be supported. Now of course we trust that compilers
will go further than the requirements, and support all the simple cases,
but now the ACVC tests feel they cannot go beyond the very weak requirements
of the RM in this area.

As an example, there is no requirement to accept 'size on a record AT ALL,
as far as I can tell, which means that:

  type x is record
     a,b : Boolean;
  end record;

  pragma Pack (X);

could make x'size 8, and the clause

  for x'size use 2;

is allowed to be rejected. 

Now I think this will turn out to be a mostly theoretical consideration,
since real Ada compilers will be designed to be useful, rather than
meet the minimum requirements. For example, GNAT of course supports
the above size clause. Still, I would have preferred stronger rules.
Maybe the ARG will visit some of the weak areas so that the formal
definition better reflects reality.

Going back to 9-bit packed fields, this would generate a LOT of code, and
my feeling is that a compiler should follow the Ada 83 guidelines, and
only accept clauses that map nicely to the hardware.

Of course if a lot of people needed this, GNAT would provide it. So far
we have ZERO customers with this requirement, so it has negative
infinity priority :-)