Re: Representation Clauses And Freezing

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"Marin D. Condic" <mcondic-nospam@acm.com> writes:

> Stephen Leake wrote:
> > > Making the compiler happy isn't really the issue. If I could accept
> > > whatever the compiler insisted on giving me, then I wouldn't need a
> > > representation clause, right?
> > 
> > But you can give a rep clause. It's just not the same one as you could
> > give if the type were public. So I don't understand what the problem is.
> > 
> Are you serious? What good is a rep clause unless it is the rep clause
> that *I* want? If any old rep clause would do, then why bother putting
> one on there at all? Decoration?

The difference was in the size and alignment representation clauses:

You wanted:

   for Rec_Type use record
      Field_01        at  4 range 0..15 ;
      Field_02        at  6 range 0..15 ;
      Field_03        at  8 range 0..15 ;
   end record ;
   for Rec_Type'Size use 10 * System.Storage_Unit;
   for Rec_Type'Alignment use 4;

The compiler will accept:

   for Rec_Type use record
      Field_01        at  4 range 0..15 ;
      Field_02        at  6 range 0..15 ;
      Field_03        at  8 range 0..15 ;
   end record ;
   for Rec_Type'Size use 16 * System.Storage_Unit;
   for Rec_Type'Alignment use 4;

The fields you explicitly located are in the same places. I'm not
clear why you can't live with this size and alignment for the record.

> Try to imagine that you want to line up a data type to match a hardware
> register or a message coming into a system from the outside world. You
> have to put a rep clause on the data type so that specific bits, bytes
> and words fall into specific positions. Having the compiler reject your
> rep clause and suggest another does absolutely no good and is totally
> pointless.

Clearly the size can't matter, since the only compiler knows the tag
size. I can see that alignment might matter, but it should be simple
to get the message into the right alignment in the first place. Is
that the problem?

You also indicate below that you want to specify the locations of
additional components in derived types, and that there seems to be
padding at the end of Rec_Type above. Instead, assume the extra space
is actually additional tag information, and move your fields down:

   for Rec_Type use record
      -- tag seems to be 10 bytes
      Field_01        at  10 range 0..15 ;
      Field_02        at  12 range 0..15 ;
      Field_03        at  14 range 0..15 ;
   end record ;
   for Rec_Type'Size use 16 * System.Storage_Unit;
   for Rec_Type'Alignment use 4;

Oops, the compiler doesn't like this either; it wants more space. So I
don't know what's going on, and I can see that this will not work for
derived types; you can't live with "gaps" in the representation.

So I am reduced to suggesting that you call ACT, and ask them how to
make it work (you are a paying customer?). They may know a
work-around, or they may be able to change the compiler to do what you
want.

> <snip>

> Yada Yada Yada. Trust me on this - I've done a lot of message passing
> stuff and I've always found Ada to be a real nasty bitch (especially 83)
> when trying to use it for this kind of application. It is a *lot* easier
> to get this out of C or other languages that pretty much let you toss
> type safety out the window. (Don't take this as an endorsement of C -
> just an illustration.)

Perhaps you see it as "easier" in C because C doesn't have tagged
types, so none of the issues you are raising here occur. 

You can always convert a tagged record into an equivalent variant
record. Perhaps you cannot afford the run-time overhead to do this, so
you are trying to map the tagged record directly onto the byte stream.
I agree that is a neat way to do things.
 
> <snip>

> I think the reason this problem annoys me so much is that over the
> years, Ada has taken a lot of heat from real time programmers because it
> was viewed as too restrictive. I've defended the language in most cases
> because I knew it well enough to know that there was usually some way of
> getting what you needed out of it. In the arena of message passing
> systems, I've always had to conceed that Ada made you do so many
> butt-ugly things to get what you needed done that it almost wasn't worth
> it.

But you are comparing apples and oranges. C has no tagged types. If
you want to say "message passing is easier in C than in Ada", please
be sure you are comparing variant records in each, not variant records
in C to tagged records in Ada!

> Ada95 fixed a lot of sore spots for the real time and embedded
> world, but I still can't build the message passing stuff in an
> elegant and efficient way - not unless I find a compiler that will
> let me get absolute control over the representation of the tagged
> types. Either that or give me a "union" and pointers I can translate
> into arrays. :-)

You have "union" and pointers. Either via Unchecked_Conversion, or via
pragma Unchecked_Union.

Take the C solution you like, and translate into Ada. Then you'll have
the best of both worlds!

-- 
-- Stephe