Re: Simple Question - Direct Access to memory with ADA

["Pat Rogers" <progers@classwide.com>]

>   Sorry for the simple question - I was wondering the most efficient way
> (moral arguments aside) to get direct access to memory in ADA 95
> (specifically using the GNAT compiler) - assuming the OS allows access
> to it. Its quite
> easy to do in C (a couple of lines to write to a memory location)
>
> *my_int_ptr = (int *) 0xF00BA;
> etc..
> This can easily be macro/funcionalized.
>
>   I could use an Address Clause for each location in memory I wish to
> access,
> this could become tiresome for large chunks of memory. There doesnt seem
> to be any provided service from gnat system packages to perform this
> function (probably for very good reasons).

This need not be vendor-specific.

If the large chunk is contiguous, use an array type and map the entire array via
a single address clause (specifying the starting address of the array).  Use the
predefined array type System.Storage_Elements.Storage_Array because it is
guaranteed to be represented contiguously.  Then access memory by indexing into
the array.  However, at any index location the type of value is the component
type of Storage_Array, ie Storage_Element.  Storage_Element is a modular numeric
type (ie unsigned).  If accessing memory in terms of an unsigned numeric type
isn't what you want, you'll need to do something else.  For example, you could
define a record type, including its representation, to contain all the kinds of
different elements at different memory locations in terms of offsets from the
beginning of the record, and then map an object of that type with a single
address clause (like the array type above).

Alternatively, you can use the predefined facility intended for this purpose:

        System.Address_To_Access_Conversions

This is a generic package that gives you type-safe "peek and poke" access to
memory, much like the C code you showed.  It does the necessary work to convert
addresses to access values (which may or may not be identical to what you would
get with unchecked conversion).  Given the access values (ie, pointers) you then
dereference them to access the memory in terms of the type of value supposedly
at those memory locations (hence the "peek/poke" terminology of old).  This is a
much more dynamic approach, with corresponding flexibility, but will be a little
slower than mapping things once using the above approaches.

>   will I need to use the  pragma Atomic as well?

Are tasks concurrently accessing and updating the storage?

> Am I going to have to resort to Unchecked_Conversion?

Probably not, but if you did that would not be an "evil" thing unless you make
the clients do it all over the code.  If you have to do it, hide it behind a
functional interface so that it only occurs within your implementation.

> I hope I have made the question clear.

Hope that helps,

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance