NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/ada/3810

Internet Message Format | 1992-12-23 | 4.1 KB

Path: sparky!uunet!paladin.american.edu!gatech!prism!jm59
From: [e-mail] (MILLS,JOHN M.)
Newsgroups: comp.lang.ada
Subject: Re: Using Shared memory from Ada code.
Message-ID: <[e-mail]>
Date: 23 Dec 92 14:39:19 GMT
References: <[e-mail]>
Organization: Georgia Institute of Technology
Lines: 79

In article <[e-mail]> [e-mail] (Bill 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: [e-mail]
 ... Not so fast -- I'm still thinking.