Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!brutus.cs.uiuc.edu!wuarchive!decwrl!ucbvax!hplabs!hp-ses!hpcc01!hpcmfs!notes
From: notes@hpcmfs.CORP.HP.COM (Notesfiles owner )
Newsgroups: comp.unix.wizards
Subject: Re: Shared memory and FORTRAN
Message-ID: <14610001@hpcmfs.CORP.HP.COM>
Date: 9 Feb 90 20:55:28 GMT
References: <6935@lynx.UUCP>
Organization: HP Corporate Manufacturing Factory Systems, Palo Alto, CA
Lines: 28

/ hpcmfs:comp.unix.wizards / m5@lynx.uucp (Mike McNally) /  8:44 am  Feb  8, 1990 /
>A potential customer of ours is currently using an OS (I don't know
>which one) that provides a nifty (in a gross FORTRAN kind of way)
>inter-process shared memory facility.  The FORTRAN code declares
>"global" COMMON blocks, which (I assume) get tagged by the linker such
>that the executable file has magic goomers in it.  The magic goomers
>tell the loader that a shared memory segment should be allocated (and
>maybe where it should be, since it would be kinda hard for the loader
>to relocate the whole mess on the fly).
>
>Anyhow, does anybody know of a mechanism (similar to the one above or
>otherwise) that would allow a FOTRAN program easy access to shared
>memory?  I don't do FORTRAN on a regular basis, so I'm pretty
>ignorant; maybe the global COMMON mechanism is COMMONplace.  

	Fortran COMMON is the equivalent of extern in C, import & export 
in Pascal (I think that they are the keywords in Pascal).

	Speaking for HP's RTE (Real Time Executive) only, shared memory
is allocated a specific block of 'hardware memory'. The allocation -how much
memory to reserve for shared memory and nothing else- is done at system
generation time (something like kernel reconfiguration). 
All shared memory segments point to that hardware -absolute- address.
The symbol table is built accordingly.

	To use it, all programs must have in their source exactly the same
COMMON statement : the sequence of how variables are declared in that block,
implies its relative location in shared memory.