Re: System.Address_to_Access_Conversions

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

nabbasi@EARTHLINK.NET writes:
>In article <6ofqvs$alm@hacgate2.hac.com>, "David says...
>
>>  Typically you will want to use a record representation clause to
>>make the memory layout correspond to the harware requirements.  Using a
>>tagged type in such a sitiuation is not a good idea, because the tag is a
>>"hidden" data field within the record which certainly will have no
>>correspondence with the hardware-required memory layout.
>>
>
>I read somewhere that the tag position within a record is always defined,
>it is the first element always, right? not sure what's its size, I assume
>it is an address to someother tag related information somewhere else, so its
>size is also known, right?
>
    I went around the block on this one a while back. So far as I
    could determine, the Ada95 RM defines nothing about where the tag
    resides - or for that matter that it has to be kept with the
    record at all, etc. I think they wanted to say "The most obvious
    way to implement it is with a tag field that is hidden within the
    record - but if you think of a more clever way of doing it, the
    standard won't get in your way."

    The bad news is that not only does the standard not specify how
    big or where the tag field lies, but it also gives you no control
    over where to put it. You can't use representation clauses to
    control the positioning of the tag or its size and you can't
    control its content. This made tagged records a major nuisance to
    me when trying to utilize them in a communications situation where
    I wanted to beam the bits down a wire.

    There is a way to use streams to get rid of the tag information if
    you need to do it, but if you are in some way interested in
    utilizing tagged records to overlay physical hardware, etc., you
    will find there are no good answers. At best, you can determine
    how the tag is handled by the specific version of the specific
    compiler you are using & build your representation around that
    information. You may fight loosing battles with the compiler over
    word alignment and memory allocation because apparently compilers
    won't trust you when you say "No, I really mean it: put this field
    here." In the end you will have a non-portable solution that is
    volatile and subject to change without notice by your compiler
    vendor.

    If you come across information that suggests a solution to
    controlling representation of tagged record types that sounds
    standard and portable, I'd be interested in hearing about it.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "The race is not always to the swift, nor the battle to the
    strong - but that's the way to bet."
        --  Damon Runyon
=============================================================================