Path: utzoo!utgpu!cunews!cognos!jimp From: jimp@cognos.UUCP (Jim Patterson) Newsgroups: comp.sys.hp Subject: Re: Problem using shared memory on a HP 9000/720... Message-ID: <9581@cognos.UUCP> Date: 29 Apr 91 14:36:16 GMT References: Reply-To: jimp@cognos.UUCP (Jim Patterson) Distribution: comp Organization: Cognos Inc., Ottawa, Canada Lines: 50 In article rdm@cernapo (Alphonse Rademakers) writes: >Hi, > I have a problem using shared memory (shm calls) on the HP 9000/720. >I've made a little program that creates a shared memory segment and >accesses it via an offset from a base array (in Fortran). >The offset from the base array was returned by the routine >that created the shared memory segment (in C). I came across a similar problem on an HP3000/935 (also HP-PA architecture, completely different O/S). It may be related to the fact that the HP-PA 32 bit address really isn't a 32-bit flat address, but a reference to one of 4 30-bit address spaces. The high order 2 bits of an address are in fact segment selectors. (There's a 32-bit address space lower down, but you can only get at it via 64-bit pointers which aren't exposed in the HP-UX system). With your test program, it appears that shmget() returns an address with the segment bits set to 3 (e.g. 0xc0019000). Addresses in the data space have the segment set to 1 (e.g. 0x40004bb8). So, your offset is trying to cross segments which is causing your memory fault. It turns out that this problem doesn't always appear, but does appear where the BASE address is in one segment but the BASE+INDEX address is in a different segment when using an indexed instruction mode. This didn't come up that much in C but often enough. Looking at your code, it looks like it will come up often or always because references are always via indexes to IBASE. This behaviour is all perfectly legitimate as near as I can tell. It doesn't appear to violate anything in ANSI C or, I suspect, standard Fortran. It's the program which is illegitimate as I suspect you know. The C program is setting up a situation where a reference to one object (the shared space) is being disguised as a reference to another completely unrelated object (the BASE array). This violates the 'contract' the compiler is fulfilling, which assumes that BASE is an array of known size in the data area. You might be able to fool the FORTRAN compiler into separating the address calculation from the dereference. (Once the machine loads the actual address into a register, it's okay; it only has trouble if the actual address is arrived at from a base/index instruction mode). If you pass an array-slice to a SUBROUTINE which points to the area you want to access, FORTRAN should generate code to reference it directly in the correct segment. Sorry, my FORTRAN is pretty rusty so I'm not going to attempt to construct code to do this. -- Jim Patterson Cognos Incorporated UUCP:uunet!mitel!cunews!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 x6112 3755 Riverside Drive Ottawa, Ont K1G 3Z4