Re: Representation Clauses And Freezing

["Marin D. Condic" <mcondic-nospam@acm.com>]

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?

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.


> Compilers are free to choose the implementation for tagged types. This
> compiler apparently has a representation for private tagged types that
> is slightly different then for public tagged types. Your rep clause
> does not completely specify the full tagged type. So again, what is
> the problem?
> 
Thats just another way of saying "it is legal behavior for a compiler to
reject all representation clauses" - which is another way of saying that
it is totally useless. I understand that a compiler needs to be in a
position to pick the representation of the tag, but I ought to be able
to own the entire rest of the record - including any derivations
thereof. If the compiler wants to own bits 0..31, that's fine with me,
but I want to own bits 32..N and get exactly what I specify. No longword
alignments I didn't ask for. No extra spare space between fields.
Nothing but precisely what I specify - otherwise it does me no good. You
might just as well have said "representation clauses on tagged records
are illegal in Ada" because it amounts to the same thing.

> 
> First, the rep clause you gave was rejected by the compiler, so you
> need to find out why and/or fix the rep clause so it will be accepted.
> 
Bzzzzzzzt. Wrong answer. :-) My rep clause expresses a legitimate
representation of the data in legal syntax. A compiler is free to reject
it and claim to be validated. Fair enough. But if it rejects it and
claims to be useful - "just change your representation to my
representation" then I must regretfully reject the compiler for this
application.

Now if there is another way of *expressing* the same representation that
the compiler will like better, I'll accept that as a workaround - but
that's like saying "if it won't accept it on a tagged record, then just
don't use tagged records - use a regular record or an array of raw bytes
or something else." Sure, you can do that, but then you lose the use of
the language feature and you're back to asking what good is it to have a
rep clause for a tagged record? Why not just program the whole thing in
assembly language?

> 
> You'll have to be more specific. I don't see a significant difference:
> 
> Method 1:
> 
> type Specific_Rep_Type is record
>     something      : integer_32;
>     something_else : integer_32;
> end record;
> for Specific_Rep_Type use record
>    something      at 0 range 0 .. 31;
>    something_else at 4 range 0 .. 31;
> end record;
> for Specific_Rep_Type'size use 64;
> 
> type Object_Type is tagged record
>    specific_stuff : Specific_rep_Type;
> end record;
> 
Is the following statement guaranteed to be true?

Object_Type'Size = Specific_Rep_Type'Size

Well of course not. We've got to account for the tag so I'll accept
subtraction of a constant to remove the tag. Is the following statement
true in all cases (assuming the tag is a 32 bit word)

(Object_Type'Size - 32) = Specific_Rep_Type'Size

Now go extend that Object_Type with Another_Specific_Rep_Type and are
you guaranteed that

(New_Object_Type'Size - 32) = (Specific_Rep_Type'Size +
Another_Specific_Rep_Type'Size)

The answer, BTW, is "no". The first one *may* hold by accident, but is
not guaranteed because Object_Type may extend its size to do word
alignment, etc. The second one doesn't hold, again because the compiler
may choose to start the additional fields at any offset from the
beginning of the record.

Why do I want to do this? I suppose its not going to be sufficient to
say "because I just do!" :-) Try putting an overlay of a byte array on
top of the record. Why? It's a really fast way of translating the record
into something you can run down the wire to someone else. You get your
structured data for 99% of the computing and you get your raw data for
the 1% of the computing that needs to treat it as such. Isolating that
in the non-visible part of the base class and making it work for all
derived classes is a *really slick* way of building a message passing
system. You probably also want to put a word array or longword array
overlay on top of it so you can compute checksums. You also want 'Size
to give you what you expect so you can compute the size of the message.
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.)

And please don't offer me 'Read and 'Write. Not only is it data motion,
but it degenerates to too many procedure calls and still leaves you with
no good way of computing the message size or checksums as you go along.
I could eat the efficiency issues on many apps, but many others can't
ignore it.


> You don't have a "restriction", you have a "difference in
> implementation specifics between public and private tagged types".
> Perfectly legitimate according to the Ada 95 standard.
> 
And as I said before, totally useless. Just because it is "legal"
doesn't make it "useful".

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. 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. :-)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity."

    -- Martin Luther King, Jr
======================================================================