System.Address_to_Access_Conversions

System.Address_to_Access_Conversions

[jsanchor]

Hello Everyone:  In my program I have some system address and I have to move
data to it. I am using access types to do this. I don't want to use Unchecked
conversion. So I started looking at a new feature Ada95 has
System.Address_to_Access_Conversions. I have

type Dummy_Type is tagged private;
type Ptr_to_Data_Type is access all Dummy_Type'class;

private
  type Dummy_Type is tagged
      record
         checksum : Storage_Element;
      end record;

Dummy       : Dummy_Type;
Ptr_to_Data : Ptr_to_Data_Type;


I want Ptr_to_Data to point to some system address, say, 16#00E00000#
with unchecked conversion I could say,

function Convert_to_Pointer is new UNCHECKED_CONVERSION (
                                                  source => system.address,
                                                  target => Ptr_to_Data_Type);

Ptr_to_Data := Convert_to_Pointer(16#00E00000#);

I tried using System.Address_to_Access_Conversions,

package Convert_to_Pointer is new
         System.Address_to_Access_Conversions(system.address);

Data_Ptr : Convert_to_Pointer.Object_Pointer;

Data_Ptr := Convert_to_Pointer(16#00E00000#); --This is my problem!!
-- I need a type Ptr_to_Data_Type, NOT Convert_to_Pointer.Object_Pointer

I tried casting
Ptr_to_Data := Ptr_to_Data_Type(Data_Ptr); --It compiled..but when I ran it
SEGMENTATION FAULT ERROR showed up.
Can anybody suggest how do I get the correct access type to point to memory.

Thank you in advance.
Jay S.


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: System.Address_to_Access_Conversions

[Stephen Leake]

jsanchor@my-dejanews.com writes:

> <snip>
> 
> I tried casting
> Ptr_to_Data := Ptr_to_Data_Type(Data_Ptr); --It compiled..but when I ran it
> SEGMENTATION FAULT ERROR showed up.
> Can anybody suggest how do I get the correct access type to point to memory.

You have the correct Ada syntax (that's why it compiled), but the
Operating System is not letting you write to that address (that's what
SEGMENTAION FAULT means).

The cure depends on what OS you are using. Most will NOT let you write
directly to arbitrary addresses (I assume this is a hardware device
register?) from user code. You will need to write a piece of code that
runs in kernel mode (normally called a "device driver").

If you give us more details about what's at that memory location, what
OS and CPU you are using, we might be able to help.
> 
> Thank you in advance.
> Jay S.
>
 You're welcome

-- Stephe

Re: System.Address_to_Access_Conversions

[Robert Dewar]

Nasser says

<<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?
>>

There is no such requirement, in fact there is not even a requirement
that the tag be in the record value at all, and there is a perfectly
reasonable implementation which avoids this (although I don't think any
Ada 95 compiler uses it!)

Re: System.Address_to_Access_Conversions

[jsanchor]

In article <35AB9C59.74E529E0@magic.fr>,
  Pascal MALAISE <malaise@magic.fr> wrote:
> jsanchor@my-dejanews.com wrote:
>
> > I tried using System.Address_to_Access_Conversions,
> >
> > package Convert_to_Pointer is new
> >          System.Address_to_Access_Conversions(system.address);
> Don't you mean
> package Convert_to_Pointer is new
>  System.Address_to_Access_Conversions(Ptr_to_Data_Type);
>
> No, the package is correct. I want to convert a system address to an access
type.--
>
Thank you,
Jay S.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: System.Address_to_Access_Conversions

[jsanchor]

> > I tried casting
> > Ptr_to_Data := Ptr_to_Data_Type(Data_Ptr); --It compiled..but when I ran it
> > SEGMENTATION FAULT ERROR showed up.
> > Can anybody suggest how do I get the correct access type to point to memory.
>
> You have the correct Ada syntax (that's why it compiled), but the
> Operating System is not letting you write to that address (that's what
> SEGMENTAION FAULT means).
> -- Stephe
>Good catch..Stephen. After I sent the mail it hit me. Anyway, I am writing to
NVM. Thank you for your responce.
Sincerely,
Jay S.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: System.Address_to_Access_Conversions

[Anonymous]

On Mon, 13 Jul 1998 16:42:29 GMT, jsanchor@my-dejanews.com wrote:

> Hello Everyone:  In my program I have some system address and I have to move
> data to it. I am using access types to do this. I don't want to use Unchecked
> conversion. So I started looking at a new feature Ada95 has
> System.Address_to_Access_Conversions. I have
> 
> type Dummy_Type is tagged private;
> type Ptr_to_Data_Type is access all Dummy_Type'class;
> 
> private
>   type Dummy_Type is tagged
>       record
>          checksum : Storage_Element;
>       end record;
> 
> Dummy       : Dummy_Type;
> Ptr_to_Data : Ptr_to_Data_Type;
> 
> 
> I want Ptr_to_Data to point to some system address, say, 16#00E00000#
> 
> ...
> 
> I tried using System.Address_to_Access_Conversions,
> 
> package Convert_to_Pointer is new
>          System.Address_to_Access_Conversions(system.address);

This should be instantiated for type Dummy_Type'Class.

> 
> Data_Ptr : Convert_to_Pointer.Object_Pointer;
> 
> Data_Ptr := Convert_to_Pointer(16#00E00000#); --This is my problem!!
> -- I need a type Ptr_to_Data_Type, NOT Convert_to_Pointer.Object_Pointer

Try using

subtype Ptr_To_Data_Type is Convert_to_Pointer.Object_Pointer;

If you instantiate Address_to_Access_Conversions for type
Dummy_Type'Class, then this gives you what you want (access all
Dummy_Type'Class).

> 
> I tried casting
> Ptr_to_Data := Ptr_to_Data_Type(Data_Ptr); --It compiled..but when I ran it
> SEGMENTATION FAULT ERROR showed up.
> Can anybody suggest how do I get the correct access type to point to memory.

At this point you have a pointer to System.Address that you've been able
(somehow) to convert to pointer to Dummy_Type'Class. That might have
something to do with the Segmentation Fault. However, manipulation of
arbitrary addresses is tricky; here your operating system is telling you
that you are accessing memory outside the area allocated to you.

> ...

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"You brightly-colored, mealy-templed, cranberry-smelling, electric
donkey-bottom biters."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: System.Address_to_Access_Conversions

[David C. Hoos, Sr.]

jsanchor@my-dejanews.com wrote in message
<6ofn8e$5ff$1@nnrp1.dejanews.com>...
>> No, the package is correct. I want to convert a system address to an
access
>type.--


With all due respect, sir you are wrong.  Take a look at the package
specification at the end of this message.
Despite the package name, the package exports functions which convert both
ways -- i.e., To_Address, and To_Pointer.
Now, look at the function which returns an access value. The parameter of
that function is of type System.Address, and the return type is
Object_Pointer which is in turn declared as being an access to the generic
formal type Object.  Therefore, the type with which the package must be
instantiated is the type of the object which you wish to locate at your
specified address location -- not an access type or an address type, but the
actual object type.

However, there is another aspect of your original example which is a
problem.  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.

David C. Hoos, Sr.

-- begin package System.Address_To_Access_Conversions --
generic
  type Object(<>) is limited private;
package System.Address_To_Access_Conversions is
  pragma Preelaborate(Address_To_Access_Conversions);
  type Object_Pointer is access all Object;
  function To_Pointer(Value : Address) return Object_Pointer;
  function To_Address(Value : Object_Pointer) return Address;
  pragma Convention(Intrinsic, To_Pointer);
  pragma Convention(Intrinsic, To_Address);
end System.Address_To_Access_Conversions;
-- end package System.Address_To_Access_Conversions --

Re: System.Address_to_Access_Conversions

[jsanchor]

> With all due respect, sir you are wrong.  Therefore, the type with which the
package must be
> instantiated is the type of the object which you wish to locate at your
> specified address location -- not an access type or an address type, but the
> actual object type.
>
>you are correct! Definitely my mistake. The package should have been
instantiated with  dummy_type'class. Thank You.
Sincerely,
Jay S.
>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: System.Address_to_Access_Conversions

[David C. Hoos, Sr.]

jsanchor@my-dejanews.com wrote in message
<6og7km$cqi$1@nnrp1.dejanews.com>...
>>you are correct! Definitely my mistake. The package should have been
>instantiated with  dummy_type'class. Thank You.
Did you overlook my comment in my previous post about the perils of using a
tagged type for mapping to a specific address?

Re: System.Address_to_Access_Conversions

[nabbasi]

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?

Nasser

Re: System.Address_to_Access_Conversions

[David C. Hoos, Sr.]

nabbasi@earthlink.net wrote in message <6ogieq$qlo@drn.newsguy.com>...
>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 don't know where you read this information -- it is certainly not
universally true -- i.e., it's not specified by the language.  It might be
true of some particular implementation.
The location of the tag within a record is implementation-defined, and you
can define where it _isn't_ by means of a representation clause which
defines where everything else _is_.
Typically, tags are accesses to the dispatch table, but, again, the size of
an access to the dispatch table might not be known to the programmer.

In any case beacuse of the address specified in Jay's original post
(16#00E00000#) I guessed that he might be trying to overlay some
memory-mapped hardware (e.g. video ram) with his data structure, and that
just doesn't seem to me like an appropriate application of tagged types.  I
just wanted to warn of some difficulties I encountered when trying to use
tagged types where memory layout had to meet some specification in which a
tag was not part of the specified memory layout.

I notice also, that Jay's response to my 6ofqvs$alm@hacgate2.hac.com post
did not mention the tagged type problem at all, but did specify a tagged
type.

David C. Hoos, Sr.

Re: System.Address_to_Access_Conversions

[Pascal MALAISE]

jsanchor@my-dejanews.com wrote:

> I tried using System.Address_to_Access_Conversions,
> 
> package Convert_to_Pointer is new
>          System.Address_to_Access_Conversions(system.address);
Don't you mean
package Convert_to_Pointer is new
 System.Address_to_Access_Conversions(Ptr_to_Data_Type);


-- 
Pascal MALAISE		| E-mail:
22 Avenue de CHOISY	|  (priv) malaise@magic.fr
75013 PARIS		|  (prof) malaise@fr.airsysatm.thomson-csf.com
FRANCE

Re: System.Address_to_Access_Conversions

[Marin David Condic, 561.796.8997, M/S 731-96]

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
=============================================================================

Re: System.Address_to_Access_Conversions

[jsanchor]

> I notice also, that Jay's response to my 6ofqvs$alm@hacgate2.hac.com post
> did not mention the tagged type problem at all, but did specify a tagged
> type.
>
> David C. Hoos, Sr.
> I am using tagged types to identify different data records that the author of
each child package will create from my parent type Dummy_type'class, and store
them in NVM.
i.e type new_dummy_type is new my_package.dummy_type'class with
    record
      number : integer := 8;
    end record;

    new_dummy : aliased new_dummy_type;

They will call a procedure declared in my package called
   Register(access_to_block : access Dummy_type'class).

ex. my_package.Register(new_dummy'access);
Register in my_package will get the TAG
     tmp :   Ada.tags.tag;
     tmp :=  access_to_block'tag

 & the put in an array(plus, access type). And my package will poll through
this array and update NVM if there are any change to RAM copy. (To put it
simply) After reading all the comments from all who have responded I am
worried because I also thought that the TAG was the first element in the
record. I have tampered with my program ~100 times and it did stay there. (I
am not saying you are wrong just pondering).

Sincerely,
Jay S.



>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: System.Address_to_Access_Conversions

[David C. Hoos, Sr.]

jsanchor@my-dejanews.com wrote in message
<6oj1qi$n37$1@nnrp1.dejanews.com>...
<snip>
>After reading all the comments from all who have responded I am
>worried because I also thought that the TAG was the first element in the
>record. I have tampered with my program ~100 times and it did stay there.
(I
>am not saying you are wrong just pondering).
>
Well, for a given version of a given compiler, that may well be the case.
With gnat, I found (as I said in an earlier post) that I could control where
that tag _isn't_ by using a representation clause to define where everything
else _is_.

As some have pointed out, there is no requirement that the tag even be
present in the memory layout, so I wouldn't depend on the tag being there,
if it were I.

For portability, I would consider using stream I/O to read and write the
data to NVM.  Then you would have a portable representation -- i.e., the
_external_ tag -- written in memory.  You _could_ use the implementation's
default external tag value for each type, but for portability I would define
the external_tag for each type using an attribute definition clause.

In such a case, the data type which you would be referencing in the
System.Address_to_Access_Conversion instantiation would be an array of
stream_elements.

Just for what it's worth -- I hope a little more than two cents!

David C. Hoos, Sr.

Re: System.Address_to_Access_Conversions

[Matthew Heaney]

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

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

If something is a "major nuisance" to do, then you should interpret that
to mean that you shouldn't be doing it.

Do not try to send a tagged type directly across an external interface.
You must first convert the object to an external format, preferably
using the streams facility and/or the DSA.

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

No good answers, becuase the question itself is all wrong.

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

Please don't fight the language, as there are "standard and portable"
ways to get the job done.  That the representation of a tagged type
isn't under programmer control is a feature, not a flaw.

Re: System.Address_to_Access_Conversions

[nababsi]

In article <m3btqd964p.fsf@mheaney.ni.net>, Matthew says...
>
>nabbasi@earthlink.net writes:
>
>> 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?
>
>This is all wrong.  A compiler writer is free to use any implementation
>he pleases.
>

there is a paper on www.gnat.com called "Ada 9x tagged types and their
implementation in GNAT".  by Crille COmer and Brett Porter. it says:

"for many reasons, it turns out to be mandotary that any field in a tagged
type keep the same location within the record in the any descendant type",

then later on they say .."this compoenent is inserted at the top of the
record forcing the additional compoenents at the end"..

and they show a digram showing the tag field at the top of the record as
a pointer to dispatch table.

nasser

Re: System.Address_to_Access_Conversions

[Matthew Heaney]

nababsi@earthlink.net writes:

> >This is all wrong.  A compiler writer is free to use any implementation
> >he pleases.
> >
> 
> there is a paper on www.gnat.com called "Ada 9x tagged types and their
> implementation in GNAT".  by Crille COmer and Brett Porter. it says:

Fine, but this is a paper written about GNAT.  The only reference you
should care about wrt representation of tagged types is the Ada
Reference Manual.  

(You won't find anything in there, by the way, because the RM mandates
no particular representation.  Therefore, you can't assume one, and
you're just going to have to solve your problem some other way.)


 

Re: System.Address_to_Access_Conversions

[Charles Hixson]

Ok.  But they are just saying how THEY did it.  This doesn't imply that
everyone else did the same thing.  Or even that they will continue to do
things that way (although, public documentation is a kind of a
committment).

nababsi@earthlink.net wrote:
> 
> In article <m3btqd964p.fsf@mheaney.ni.net>, Matthew says...
> >
> >nabbasi@earthlink.net writes:
> >
> >> 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?
> >
> >This is all wrong.  A compiler writer is free to use any implementation
> >he pleases.
> >
> 
> there is a paper on www.gnat.com called "Ada 9x tagged types and their
> implementation in GNAT".  by Crille COmer and Brett Porter. it says:
> 
> "for many reasons, it turns out to be mandotary that any field in a tagged
> type keep the same location within the record in the any descendant type",
> 
> then later on they say .."this compoenent is inserted at the top of the
> record forcing the additional compoenents at the end"..
> 
> and they show a digram showing the tag field at the top of the record as
> a pointer to dispatch table.
> 
> nasser

Re: System.Address_to_Access_Conversions

[Charles Hixson]

Ok.  But they are just saying how THEY did it.  This doesn't imply that
everyone else did the same thing.  Or even that they will continue to do
things that way (although, public documentation is a kind of a
committment).

nababsi@earthlink.net wrote:
> 
> In article <m3btqd964p.fsf@mheaney.ni.net>, Matthew says...
> >
> >nabbasi@earthlink.net writes:
> >
> >> 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?
> >
> >This is all wrong.  A compiler writer is free to use any implementation
> >he pleases.
> >
> 
> there is a paper on www.gnat.com called "Ada 9x tagged types and their
> implementation in GNAT".  by Crille COmer and Brett Porter. it says:
> 
> "for many reasons, it turns out to be mandotary that any field in a tagged
> type keep the same location within the record in the any descendant type",
> 
> then later on they say .."this compoenent is inserted at the top of the
> record forcing the additional compoenents at the end"..
> 
> and they show a digram showing the tag field at the top of the record as
> a pointer to dispatch table.
> 
> nasser

Re: System.Address_to_Access_Conversions

[Robert Dewar]

nabassi said

<<there is a paper on www.gnat.com called "Ada 9x tagged types and their
implementation in GNAT".  by Crille COmer and Brett Porter. it says:

"for many reasons, it turns out to be mandotary that any field in a tagged
type keep the same location within the record in the any descendant type",

then later on they say .."this compoenent is inserted at the top of the
record forcing the additional compoenents at the end"..

and they show a digram showing the tag field at the top of the record as
a pointer to dispatch table.
>>


Just because one particular versoin of GNAT made this choice, does not
mean that other compilers wlil make the same choice, or even future
versions of GNAT. The paper you refer to is a discussion of the implementation
techniques planned for GNAT 7 years ago. It is not even accurate with respect
to the current GNAT implementation, let alone being a necessarily accurate
description of what other Ada 95 compilers nmight do!

Re: System.Address_to_Access_Conversions

[Robert Dewar]

Matthew said

<<Fine, but this is a paper written about GNAT.  The only reference you
should care about wrt representation of tagged types is the Ada
Reference Manual.
>>

Not even that is true, as I pointed out, this paper is ancient at this stage,
and cannot even be taken as a necessarily accurate description of GNAT as
it exists today.

Re: System.Address_to_Access_Conversions

[Robert Dewar]

Charles said

<<Ok.  But they are just saying how THEY did it.  This doesn't imply that
everyone else did the same thing.  Or even that they will continue to do
things that way (although, public documentation is a kind of a
committment).
>>


That was not public documentation, it was simply a technical paper 
describing our thoughts at the time on how to implement one particular
feature in Ada 95. Not the slightest commitment was implied by this
paper.

The current documentatoin of GNAT does not guarantee the layout of
tagged types, and it is quite wrong to write code that depends on this
layout, even if you intend to use only GNAT.

Re: System.Address_to_Access_Conversions

[nabbasi]

In article <dewar.901493013@merv>, dewar@merv.cs.nyu.edu says...

(ref. paper on www.gnat.com on tags)

>Not even that is true, as I pointed out, this paper is ancient at this stage,
>and cannot even be taken as a necessarily accurate description of GNAT as
>it exists today.
>

It would be nice if one day some GNAT expert can write more updated paper 
on GNAT internals and how they implement things like tags and other 
important ada95 features. (I know, I can just look at the code, right?  :)

Nasser

Re: System.Address_to_Access_Conversions

[Matthew Heaney]

nabbasi@earthlink.net writes:

> 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?

This is all wrong.  A compiler writer is free to use any implementation
he pleases.

Don't use tagged types to exchange data across an external interface
(unless you're using the DSA).  Use a straight record type, and specify
a representation clause to match the characteristics of the hardware.

Why do programmers like to use tagged types for everything?  Choose the
simplest type for the job, not the most complex.

To paraphrase Robert's comment in a recent post, just because you buy a
super-fancy socket wrench doesn't mean you have to throw away all your
other wrenches!

Re: System.Address_to_Access_Conversions

[Marin David Condic, 561.796.8997, M/S 731-96]

Matthew Heaney <matthew_heaney@acm.org> writes:
>
>"Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM> writes:
>
>>     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.
>
>If something is a "major nuisance" to do, then you should interpret that
>to mean that you shouldn't be doing it.

    Actually there is a good reason to try to do this. When writing
    software to do communication of messages down a wire, you really
    want to "have it both ways" You want strongly typed data so that
    you can properly interpret the messages, yet you also want the
    ability to treat them as raw bytes when doing the actual
    transmit/receive. Without going into it in too much depth, what I
    was trying to do was something that is easily done in assembly or
    other weakly typed languages (without any protection) but has been
    traditionally hard to do in Ada without introducing major
    inefficiencies. Tagged records provide a mechanism with which to
    do it reasonably well, but you have to go through some gyrations
    with streams to strip out the tags. (And most folks wouldn't care,
    but when you're trying to do this on a schedule, the extra layers
    of data motion become a "major nuisance".)

>
>Do not try to send a tagged type directly across an external interface.
>You must first convert the object to an external format, preferably
>using the streams facility and/or the DSA.

    Never tried to. Unless you can control *all* of the data you are
    sending, you shouldn't be trying to send it because you don't know
    what will be at the other end. The "stream" business provides an
    answer, (maybe) but not as good a one as I would like. It would
    have been better if I had the ability to control the placement and
    content of the tag, which would mean I could strip it out or
    otherwise get the raw bits I wanted with Unchecked_Conversion. Or
    barring that, at least be able to use the tag as a message ID or,
    with known size and placement, have it "reserved" in the message
    catalog so the other side knows to ignore it.

    It would take pages to try to explain exactly what I am doing with
    tagged records in this particular situation. They can be used and
    they do provide an answer for internal architectural problems. You
    just have to beg and plead with the compiler or find a way to deal
    with double buffering timing delays because of the lack of control
    over representation issues.
>
>>     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.
>
>No good answers, becuase the question itself is all wrong.

    Which, as I recall, was the original poster's question about
    tagged records. I'm not sure why he wanted to overlay tagged
    records onto hardware, but (given that I've been there myself in
    embedded applications) I will reserve judgement on it being a good
    or bad idea. Often you have some slick software architecture plan
    and then you get down to having to connect to physical hardware
    that was designed by guys who are mostly familiar with assembly
    language programming - maybe Fortran - but have no concept of what
    you'd like to do in software. So you have to look for a way to
    connect up your slick software design with the physical
    characteristics of the hardware. (Consider that you'd like to
    apply the latest ideas of Object Oriented Programming to an
    embedded application - "Tagged records, let me introduce you to
    Hardware...") Maybe that's where he was at.

    I'd agree that it is not a desirable place to be, because you have
    so little control over the representation of tagged records. But
    that doesn't necessarily mean that a tagged record (or
    discriminated record or plain vanilla record) might not be the
    best logical representation of the problem.

>
>>     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.
>
>Please don't fight the language, as there are "standard and portable"
>ways to get the job done.  That the representation of a tagged type
>isn't under programmer control is a feature, not a flaw.
>
    Not being completely dim, I seldom tilt at windmills anymore and
    don't generally want to "fight the language". Still, I've needed
    control over tagged records and to date, the only mechanism that
    works completely is to know exactly what a given compiler produces
    and rely on those assumptions. Dangerous, volatile, and not
    standard or portable, but it has been known to work. It may be
    your only choice unless the project can afford to buy some
    compiler writers and eat the time needed to get the changes made.

    "Standard and portable" can be vastly overrated. In the embedded
    world, you quite often are looking at a situation where you are
    going to freeze the hardware and the compiler and it will remain
    thus for many years to come. In the event of "new" hardware or a
    similar system, you are almost always back at ground zero anyway,
    so you can forget "portability" without modification. (Yes, you do
    get to reuse software, but either a) it is at an abstract enough
    level where you don't care about representation anymore or b) it
    is at a sufficiently low level that you are going to have to
    change everything for hardware differences anyway, so the
    representation will have to be revisited no matter what you do.)
    Besides, a change in hardware typically means such a huge
    investment in other things that to develop the software again
    completely from the ground up is so far down in the weeds that
    nobody cares.

    I'd have to respectfully disagree about the lack of control of the
    representation of tagged types being a "feature" instead of a
    "flaw". Here's where I come from on that topic: Either a) I have
    no interest in how the bits are ordered, or b) I do. If the
    situation is A, then the compiler is free to do what it likes and
    I need no representation clause for a tagged record. If the answer
    is B, then I can look to the representation clause - which legally
    applies to tagged records - to get the control I want. If,
    however, the introduction of the representation clause only allows
    me to control the ordering of *some* of the bits, then I might
    just as well not have it at all, because that original condition
    is bistable: I either need control or I don't. So the fact that
    the representation clause won't let me deal with the tag, or the
    alignment as I extend a tagged type or in any other respect where
    the compiler is going to refuse a legitimate specification of
    representation, then there might just as well have been a rule in
    the language that said "representation clauses cannot be applied
    to tagged types".

    A prime example of this is when you have to build software which
    must respond to messages defined long ago and may be sent from
    anywhere. The bit ordering is what it is and you are not free to
    change it. So either you can control the representation of your
    data structures and take advantage of modern programming concepts
    (enumerations, discriminated/tagged records, abstract data types,
    etc.) or you can't control the representation and have to program
    at the lowest level of bit-twiddling to deal with reality.
    Naturally, I'd prefer to use the more advanced concepts and leave
    the shifting & masking of bits to the compiler.

    I've had reasons in the systems I design to use representation
    clauses for just about every kind of data type imaginable. If for
    no other reason than to guarantee the assumptions on which a
    system is founded, just in case someone tries to port the code or
    a compiler switch is made midstream. I appreciate it when the
    compiler notices that I've specified some representation is
    logically impossible. It would be nice if the compiler would warn
    you of potential inefficiencies in the representation you choose.
    It would be even nicer if the compiler were to spit out a pictorial
    memory layout of the representation you specified. But in all
    cases where I've specified what should be a legal specification
    and had it rejected by the compiler, I've cursed the developers
    for second-guessing me. The representation clause is supposed to
    be a "Trust me, I know what I'm doing" sort of thing similar to
    Unchecked_Conversion.

    Sorry for going off on a harangue - it's one of my favorite
    things to get frustrated about with compilers!

    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
=============================================================================

Re: System.Address_to_Access_Conversions

[Stephen Leake]

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

> Matthew Heaney <matthew_heaney@acm.org> writes:
> >
> >Do not try to send a tagged type directly across an external interface.
> >You must first convert the object to an external format, preferably
> >using the streams facility and/or the DSA.
> 
>     Never tried to. Unless you can control *all* of the data you are
>     sending, you shouldn't be trying to send it because you don't know
>     what will be at the other end. The "stream" business provides an
>     answer, (maybe) but not as good a one as I would like. It would
>     have been better if I had the ability to control the placement and
>     content of the tag, which would mean I could strip it out or
>     otherwise get the raw bits I wanted with Unchecked_Conversion. Or
>     barring that, at least be able to use the tag as a message ID or,
>     with known size and placement, have it "reserved" in the message
>     catalog so the other side knows to ignore it.

But that is exactly what 'input and 'output give you! You control how
the tag is represented in the stream, and where it is placed. Both
ends of the stream agree on the stream representation, but can have
different internal reps.

>     I'd have to respectfully disagree about the lack of control of the
>     representation of tagged types being a "feature" instead of a
>     "flaw". Here's where I come from on that topic: Either a) I have
>     no interest in how the bits are ordered, or b) I do. If the
>     situation is A, then the compiler is free to do what it likes and
>     I need no representation clause for a tagged record. If the answer
>     is B, then I can look to the representation clause - which legally
>     applies to tagged records - to get the control I want. If,
>     however, the introduction of the representation clause only allows
>     me to control the ordering of *some* of the bits, then I might
>     just as well not have it at all, because that original condition
>     is bistable: I either need control or I don't. So the fact that
>     the representation clause won't let me deal with the tag, or the
>     alignment as I extend a tagged type or in any other respect where
>     the compiler is going to refuse a legitimate specification of
>     representation, then there might just as well have been a rule in
>     the language that said "representation clauses cannot be applied
>     to tagged types".

I'll agree with that. If a tagged type is a good logical
representation, you can still need several untagged types to map to
the hardware, so you can apply representation clauses.

>     A prime example of this is when you have to build software which
>     must respond to messages defined long ago and may be sent from
>     anywhere. The bit ordering is what it is and you are not free to
>     change it. So either you can control the representation of your
>     data structures and take advantage of modern programming concepts
>     (enumerations, discriminated/tagged records, abstract data types,
>     etc.) or you can't control the representation and have to program
>     at the lowest level of bit-twiddling to deal with reality.
>     Naturally, I'd prefer to use the more advanced concepts and leave
>     the shifting & masking of bits to the compiler.

Again, you need two types; one that matches the predefined structure
(untagged), and one that makes it more logical (tagged).

-- Stephe