Type System.ADDRESS

Type System.ADDRESS

[Bob Gilbert]

I've run across a problem and would like a little net wisdom
on this...

The compiler I'm working with has choosen to implement the type
System.ADDRESS as static.  Although this appears to be within 
the rules of the LRM, it does present some significant limitations.

1)  It has been a frequent practice of mine to implement drivers for
    memory mapped devices using a generic, where the base address of
    the device is supplied as a generic parameter. This has allowed
    for nice reusable Ada components. Unfortunately,with a static 
    implementation of type System.ADDRESS, a representation clause 
    cannot use the generic base address supplied.

2)  Similar to the above example, I've also used generics packages 
    containing tasks associated with an interrupt, where the interrupt
    is either directly or indirectly determined by the generic 
    parameters.  Again, a static implementation of System.ADDRESS
    won't allow this.

Now I've worked around the first problem by using access types and
Unchecked_Conversion to map the generic objects, and I reconize 
that this is sort of a bastard implementation that makes assumptions
as to the implementation of the access type (not necessarily portable).

I've worked around the second problem by creating task types for each
possible interrupt, and then dynamically allocate the appropiate task
object in the generic. But this ends up looking somewhat silly as I
have many tasks types defined that are all identical except for their
address clause used to associate the interrupt (ends up looking like
I should have used a generic, so I end up writting extra comments to
explain why I didn't).

My questions are then:

 Is it reasonable for a compiler to implement System.ADDRESS as static?  

 Is it reasonable for the language to allow this?

 Is there a better way to work around the limitations?

Thanks,

    Bob

Re: Type System.ADDRESS

[Tucker Taft]

What do you mean by "static" when referring to System.Address?
-Tucker Taft

Re: Type System.ADDRESS

[Bob Gilbert]

In article IEr@inmet.camb.inmet.com, stt@dsd.camb.inmet.com (Tucker Taft) writes:
->What do you mean by "static" when referring to System.Address?
->-Tucker Taft

I wish I knew exactly what I mean by static, but from the vendor
in question they state:

  Any assignments to type System.Address require a static expression.

Apparently this limitation is what mucks up my generics.

-Bob

  

Re: Type System.ADDRESS

[Norman H. Cohen]

In article <395ecb$bjq@theopolis.orl.mmc.com>, rgilbert@orl.mmc.com (Bob
Gilbert) writes: 

|> I wish I knew exactly what I mean by static, but from the vendor
|> in question they state: 
|>
|>   Any assignments to type System.Address require a static expression.

That strikes me as a bogus implementation.  I'm surprised this gets by
the ACVC.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Type System.ADDRESS

[Tucker Taft]

In article <395ecb$bjq@theopolis.orl.mmc.com>,
Bob Gilbert <rgilbert@orl.mmc.com> wrote:

>In article IEr@inmet.camb.inmet.com, 
>stt@dsd.camb.inmet.com (Tucker Taft) writes:

>->What do you mean by "static" when referring to System.Address?
>->-Tucker Taft
>
>I wish I knew exactly what I mean by static, but from the vendor
>in question they state:
>
>  Any assignments to type System.Address require a static expression.
>
>Apparently this limitation is what mucks up my generics.

I suspect the limitation has to do with "address clauses,"
rather than "assignments."  I am not surprised that a vendor
requires the address in an address clause to be a link-time
constant.  If they do shared generics, that probably means
you can have an address clause inside a generic.

Address clauses are relatively nonportable in general,
though we hope to see some improvement with Ada 9X.

In the meantime, a somewhat (;-) more portable solution is
to use access values, defined by an unchecked conversion from 
System.Address.  So long as the designated subtype is
not an unconstrained array subtype, most compilers
have no problem converting Addresses to access values.
(Rational compilers used to be an exception -- I don't know whether
Apex is any different in this regard.)

Note that Ada 9X has a package designed explicitly for
this conversion (System.Storage_Elements.Address_To_Access_Conversions).

>-Bob

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

Re: Type System.ADDRESS

[Bob Gilbert]

In article 7M7@inmet.camb.inmet.com, stt@spock.camb.inmet.com (Tucker Taft) writes:
->In article <395ecb$bjq@theopolis.orl.mmc.com>,
->Bob Gilbert <rgilbert@orl.mmc.com> wrote:
->
->>In article IEr@inmet.camb.inmet.com, 
->>stt@dsd.camb.inmet.com (Tucker Taft) writes:
->
->>->What do you mean by "static" when referring to System.Address?
->>->-Tucker Taft
->>
->>I wish I knew exactly what I mean by static, but from the vendor
->>in question they state:
->>
->>  Any assignments to type System.Address require a static expression.
->>
->>Apparently this limitation is what mucks up my generics.
->
->I suspect the limitation has to do with "address clauses,"
->rather than "assignments."  I am not surprised that a vendor
->requires the address in an address clause to be a link-time
->constant.  If they do shared generics, that probably means
->you can have an address clause inside a generic.

You're correct about the limitation having to do the address
clauses. But the compiler in question here apparently requires
the address clause to be a compile-time constant. I've used
address clauses in generics with other Ada compiler's with
no problems.  For some reason this compiler puts this limitation
on the use of address clauses (they claim it is due to their
method of implementing System.Address ?).

->Address clauses are relatively nonportable in general,
->though we hope to see some improvement with Ada 9X.
->
->In the meantime, a somewhat (;-) more portable solution is
->to use access values, defined by an unchecked conversion from 
->System.Address.  So long as the designated subtype is
->not an unconstrained array subtype, most compilers
->have no problem converting Addresses to access values.
->(Rational compilers used to be an exception -- I don't know whether
->Apex is any different in this regard.)

This is the method I have turned to. My problem is that I
prefer to exploit the features designed into the language 
to accomplish their intended purpose. Address clauses are
there for mapping data to memory and interrupts to tasks,
and it bugs me a little to not be able to do this (at least
with generics). Resorting to using access types and unchecked 
conversion to work around the problem seems to be contrary
to their intended purpose. I hope I don't seem overly up-
tight over this issue, but things like this do tend to errode
the rational for using the language (readability, portability,
etc.), and being an Ada supporter I'd like to see these sort
issues confronted and solved (I'm just not sure if the problem
is with the compiler vendor, the language specification, me, 
or some combination of the above).
 
->Note that Ada 9X has a package designed explicitly for
->this conversion (System.Storage_Elements.Address_To_Access_Conversions).

Looking forward to it :-).

->
->>-Bob
->
->-Tucker Taft  stt@inmet.com
->Intermetrics, Inc.
->Cambridge, MA  02138

BTW - Just what are "shared generics"?

-Bob

Re: Type System.ADDRESS

[Robert I. Eachus]

In article <393k18$huv@theopolis.orl.mmc.com> rgilbert@orl.mmc.com (Bob Gilbert) writes:

 > I've run across a problem and would like a little net wisdom
 > on this...

 > The compiler I'm working with has choosen to implement the type
 > System.ADDRESS as static.  Although this appears to be within 
 > the rules of the LRM, it does present some significant limitations.

  Huh?  type System.ADDRESS should always be static (although since it
is implementation defined, it doesn't need to be an integer type.

  If you mean that the address in an Address clause is required to be
static, this is wrong.  RM13.1(10) allows an implementation to limit
representation clauses "to those that can be handled simply by the
underlying hardware." However staticness is a compile-time vs.
run-time issue that has nothing to do with the actual hardware.

 > Is it reasonable for a compiler to implement System.ADDRESS as static?  
Yes. (See above.)

 > Is it reasonable for the language to allow this?
Same answer.

 > Is there a better way to work around the limitations?
Do you have a support contract with the vendor?  If so make it his
problem.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Type System.ADDRESS

[David Emery]

>  Any assignments to type System.Address require a static expression.

This sounds like a compiler bug to me.  

First, the following is legal Ada, i.e. you can compute arbitrary
values of type System.address and assign them to variables of the
type: 
  
    X : system.address;
    A, B : integer;
  begin
    if (some_random_event) then
      X := A'address;
    else
      X := B'address;
    end if;
  end;
  
Let's now look at address representation clauses.   For instance,
given Address A, the address of an integer, the following is legal
Ada: 
  
  I : integer;
  for I use at A;

Ada83 (Ada87) RM, 13.5(2) says that the expression must be a
"simple_expression".  This is NOT the same as a
"static_simple_expression" (e.g. 13.4 (2), alignment_clause for a
record representation).  

Therefore the following is legal Ada (although potentially erroneous):
  
  with System;
  function I_at_addr (addr : System.address)
      return integer
  is
     the_object : integer;
     for the_object use at addr;
  begin
     return the_object;
  end;

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Type System.ADDRESS

[Robert Dewar]

Bob, what do you mean by implementing Address as static? this is a use
of the term static that does not seem to correspond to its technical
meaning in Ada, and I just don't understand what you mean. Can you give
a specific example of the problems you are having.

It is certainly legitimate to implement Address as a static subtype, but
I don't thing this is what you are talking about!

Re: Type System.ADDRESS

[Robert Dewar]

"  Any assignments to type System.Address require a static expression."

clearly an unwarrented and incorrect assumption. I am surprised that a
compiler can validate with this mistake.

Re: Type System.ADDRESS

[Bob Gilbert]

In article 89c@schonberg.cs.nyu.edu, dewar@cs.nyu.edu (Robert Dewar) writes:
->Bob, what do you mean by implementing Address as static? this is a use
->of the term static that does not seem to correspond to its technical
->meaning in Ada, and I just don't understand what you mean. Can you give
->a specific example of the problems you are having.
->
->It is certainly legitimate to implement Address as a static subtype, but
->I don't thing this is what you are talking about!

The problem appears when using address clauses for either mapping
objects to memory and/or associating task entries with an interrupt.

Maybe the following example will help:

  with System;
  package Address_Clause is

    type SYSTEM_TYPE is (Ax, Bx);

    type BASE_ADDR_ARRAY is array (SYSTEM_TYPE) of SYSTEM.ADDRESS;

    X_Base_Table : constant BASE_ADDR_ARRAY :=
                      BASE_ADDR_ARRAY'(Ax => 16#0020_0000#,
                                       Bx => 16#0010_0000#);

    -------------------------------------------------------------
    -- In the ultimate implementation, this package would be    -
    -- a generic where the array index (Ax) to identify the     -
    -- system being used, would be a generic parameter supplied -
    -- by the instantiation.  The generic implementation is not -
    -- shown to avoid unnecessary complications.                -
    -------------------------------------------------------------
    XBase   : constant SYSTEM.ADDRESS := X_Base_Table(Ax);
    XAddr_1 : constant SYSTEM.ADDRESS := XBase + 0;

    X1 : INTEGER;
      for X1 use at XAddr_1;

  end Address_Clause;


When I compile the above code I get the following error:

    X1 : INTEGER;
      for X1 use at XAddr_1;
                       ^1
  ***  1 Error 3271: A static expression is expected here (4.9) 

This is what I feel is an unreasonable limitation.

-Bob

Re: Type System.ADDRESS

[David Emery]

>But the compiler in question here apparently requires the address
>clause to be a compile-time constant.

If this is so, the compiler is wrong.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------