From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 23 Dec 92 14:39:19 GMT From: prism!jm59@gatech.edu (MILLS,JOHN M.) Subject: Re: Using Shared memory from Ada code. Message-ID: <78757@hydra.gatech.EDU> List-Id: 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.