Using Shared memory from Ada code.

Using Shared memory from Ada code.

[agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!menudo.uh.edu!lob]

I have a couple of questions needing serious answers.

First question:

At work, we are developing a rather large, near-realtime application
in Ada.  The application will consist of several processes (POSIX
environment eventually, UNIX for the time being) with shared memory
to be attached among all of the processes.

I have read an early version of Ted Baker's report which served as
the basis for the 1003.20 efforts. In that paper, Ted has the
following comments concerning shared memory:

"...There is uncertainty about whether the compiler will generate code that
 reads and writes data through to memory. In the absence of pragmas specifying
 otherwise, ... there is no guarantee that a reference or assignment to a 
 shared memory object in the Ada source code will result in a compiler 
 generating actual read or write operations to memory......"

O.k, the question: How do I use shared memory in my Ada programs
so that the above concerns are mitigated? How do I make SURE that
every reference to a shared memory object actually uses the shared
memory?



Second question:

In the 1003.20 Ada binding we get functions which return System.Address
values.  I want to put an Ada object at the address so that all
future references to the object are actually referencing the shared
memory. How?

I would like something like the following to work (perhaps it will, the 
DEC Ada compiler swallowed it!):

-------------------------------------------------------------------------------
-
with System;
procedure Test is

  type Structures is
    record
      Name: string(1..20);
      Status : boolean := false;
    end record;
  type Structure_Lists is array (integer range <> ) of Structures;

  Shared_Mem_Address : System.address;
  List_Length : constant integer := 100;
  The_List : Structure_Lists(1..List_Length);


  function Attach ( An_Address : in System.address;
                    Length     : in integer ) return Structure_Lists is
    A_List : Structure_Lists ( 1..Length);
    for A_List use at An_Address;
  begin
    return A_List;
  end Attach;

begin
  		.
		.
	-- Somehow get a shared memory address into Shared_Mem_Address
  The_List := Attach ( Shared_Mem_Address, List_Length );
		.
		.
  The_List(Index).Status := true;
		.
		.
	-- and so forth
end Test;
-------------------------------------------------------------------------------
-
  
The question can be simply put: how do I put an Ada object at an address
in shared memory?


Regards,

Bill Lee

Re: Using Shared memory from Ada code.

[MILLS,JOHN M.]

In article <1992Dec23.040144.7581@leeweyr.sccsi.com> bill@leeweyr.sccsi.com (Bi
ll Lee) writes:
>
>I have a couple of questions needing serious answers.
>
>First question:
>
 [..deletions ..]
>
>"...There is uncertainty about whether the compiler will generate code that
> reads and writes data through to memory. In the absence of pragmas specifying
> otherwise, ... there is no guarantee that a reference or assignment to a 
> shared memory object in the Ada source code will result in a compiler 
> generating actual read or write operations to memory......"
>
>O.k, the question: How do I use shared memory in my Ada programs
>so that the above concerns are mitigated? How do I make SURE that
>every reference to a shared memory object actually uses the shared
>memory?

This is implementation dependent, but here's our approach:

We are developing a system using three cpu's (MVME147S's) in a VME environment,
and have both shared memory (our global variables) and memory-mapped I/O
buffers which receive and return arrays of ASCII traffic.

Global memory is a set of variable definitions and declarations 'with'ed
by the user packages in our various processors.

We use 'for ... use at ...' constructs and packed record definitions to
place our I/O buffers and controls, and our global memory blocks, in the
appropriate address spaces.

The memory address bases and offsets are defined as symbolic constants,
and evaluated at compilation time (no surprise). We found it necessary
to select between alternative bases for global memory using logical switches
to compile for each target processor, since (1) the global memory resided in
fact on one of the cpu cards, and thus (2) the address space for this memory
had a different offset when seen from onboard _vs_ offboard the card.
 
We defined a single global memory map and tasks were held responsible to not
to not trash other processors' data there.
This was acceptable to us because of the small size and close communications 
among our working team.  YMMV, naturally. 

A safer, more encapsulated approach would have been to subdivide the data
into "to" and "from" blocks _viz_ each processor, and then provide functions
to access the data in only the appropriate direction.  This would have
proliferated our global data definitions and also multiplied the complexity
of defining the appropriate memory basis offset for each cpu.  We decided
the simpler approach was more maintainable, and more explainable. 

We took a close look at the actual data to confirm that none of it involved
multi-word reads and writes, where cpu's could collide.  You would need some
type of semaphore data-locking mechanism if you couldn't ensure that.

We are using TeleSoft RTAda for a one-cpu system, and XDAda for the
three-cpu system.  RTAda and XDAda didn't share memory -- I mention this only
because both systems used memory-mapped I/O, implemented in the same fashion.

The 'for .. use at' is generic, but compilers' bit assignments and storage
formats must be considered in defining the records for memory-mapped I/O.
The conventions of our two compilers _were_not_the_same_ [8-<).
We also had to resort to a couple of 'unchecked conversion's. 
(They are in Ada for a reason [8*>).

Our design was heavily driven by speed requirements, we had quite a
lot of data to shepherd around (though most of it was quasi-constant --
initialization parameters, etc.), and we distrusted both the speed and the
initial handshaking of manufacturer-supplied mailboxes and sempahores.
Maybe we were too cautious.
Well, how _should_ we have done it?  (now that we're done)

Regards --jmm--

-- 
John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: jm59@prism.gatech.edu
 ... Not so fast -- I'm still thinking.