Type System.ADDRESS

[rgilbert@orl.mmc.com (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