Re: Tagged Rep Spec

[Marin David Condic <condicma@bogon.pwfl.com>]

Robert Dewar wrote:
> 
> These are not reasons for not specifying a rep clause, they
> are just reminders that the rep clause will likely be
> impl dependent, but then MANY rep clauses are impl dependent.
> 
That's fair enough. If I can always count on the compiler I have (and
its future versions!) putting a 32 bit tag at the front of the record, I
can build useful stuff from there. But it would still be nice if there
were attributes to determine the tag placement (or even if there is a
tag - one might imagine an implementation where there is no tag - or
maybe like arrays, it is "invisible" WRT representation clauses.) 

> In the case of tagged types, the tag in GNAT is a single pointer
> sized object at offset 0 in the record. Rep clauses can be
> freely used to position the specified fields of the type,
> providing that the space for the tag is not stomped on.
> 
Yes, but there is a problem with child types. I don't so much mind if
there is a tag in front of the record if it is consistently applied,
because I can consistently remove it when necessary. However, when child
records are created, they are forced onto longword alignments which
can't seem to be overriden with a rep clause. So if I want to capture
all of my "real" data and bypass "spare" fields allocated by the
compiler, I have no reliable way of doing it. With just the tag, I might
be able to compute ((X'Size / System.Storage_Unit) - 4) the proper
number of raw bytes to move, but without good control of the placement
of all subsequent fields, the rep clause quickly becomes useless. Unless
there is some trick that I'm missing?

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/