From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=BAYES_00,RATWARE_MS_HASH, RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7f5e2921f02f258f,start X-Google-Attributes: gid103376,public From: "David C. Hoos, Sr." Subject: Re: arrays into mmap'ed memory Date: 1996/08/28 Message-ID: <01bb9533$56cf0860$308371a5@dhoossr.iquest.com> X-Deja-AN: 176997701 distribution: world references: <32249A94.4A0A@joy.ericsson.se> content-type: text/plain; charset=ISO-8859-1 organization: DBH Enterprises, Inc. mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-08-28T00:00:00+00:00 List-Id: Hi Jonas, I wrote a generic package in VADS Ada for the SGI platforms under IRIX (4, 5 & 6), a couple of years ago. It was originally written for IRIX 4, then modified for IRIX 5. IRIX 5 code works for 32-bit IRIX 6. The code belongs to my former employer's client, so I can't share it with you, but I'll summarize here what I did, and the pitfalls of multi-OS versions, as I remember them. The generic instantiation parameter is a type, being the array type. Inside the generic package, the only attribute needed is the size of the array. One little pitfall here is that we couldn't use the 'SIZE attribute of the array type because in some cases we were mapping 0.6 Gb. arrays, and the number of bits in such an array is larger than can be represented with the 32-bit INTEGER type. My solution to that was to add a second generic parameter, the size of the array type in BYTES. The parameter was defaulted to zero, which meant that the size in bytes is computable from the 'SIZE attribute -- i.e., that taking the result of the 'SIZE attribute would not raise a constraint error. Thus, for the very large array, the instantiator had to supply the second parameter, giving the size in bytes, in which case the generic's elaboration code would not do the computation. If I remember, the functions provided were mmap, unmap and synchronize. These functions had equivalent Ada parameters, using a scheme mapping Ada enumeration values (possibly logically summed with a + operator) to a bit vector, to provide the functionality of logically summing the #defined constants from C, for mode (e.g., READ_ONLY), etc. If I remember correctly, the mmap procedure allowed you to specify the name of the file, the starting offset into the file, (the length of the map is defined by the instantiating type), and the file mode. An in out parameter analogous to the FILE_TYPE of Text_IO, was a limited private type (so the object could not be copied), implemented as access to a map descriptor record. The map descriptor record contained the access (the address) to the memory, and the size of the object (in bytes). These are then used by unmap, and synchronize. Oh, in addition, the package exported a function to return the access value of the map, which is then used with standard array subscripting to get at the data. Of course, my motivation for doing this was that to allocate a 0.5 Gb. object on the heap means all that memory has to be zeroed (by sbrk), and then most of it swapped out to the swap partition on the disk, because we had only 128 Mb. of RAM in the machine. Then, the 0.5 Gb. data file had to be read into this memory, with a lot more swapping, just to put things in the state that memory mapping to the file does in an instant. and, I didn't say it, but the Ada subprograms are implemented with pragma INTERFACE to the C runtime library. And, an IRIX 4/5 pitfall -- the values of the #defines for READ and EXECUTE (I think it was) were swapped between versions, so that when we ran code built on IRIX 4 on an IRIX 5 machine, memory we thought had READ access actually had EXECUTE access. On one type of MIPS processor, this caused a kernel panic. So, you could have a little fun getting this going. I hope these ramblings are of help. -- David C. Hoos, Sr., http://www.dbhwww.com http://www.ada95.com Jonas Nygren wrote in article <32249A94.4A0A@joy.ericsson.se>... > Can anybody help me with how to use mmap'ed memory in Ada. What I want > to do is mmap a large file and then access parts of the so mapped > memory via arrays. > > In C it is simple since arrays are more or less a language syntax > on top of pointers, p[i] == *(p+i). How can I connect an Ada array > to memory allocated via mmap? I do not want to store the bounds > of the array in the mapped file - the file should just be plain > ASCII. If I manage to get the array to point to the memory and > the bounds to be set correctly what will happen when Ada tries to > reclaim the array? > > Of course I could use a pointer and write my own access functions > for this pointer but I think that it would be nicer to use arrays > if possible. > > This probably sounds confused and reflects my understanding of Ada > but perhaps you get the gist of my question and so can put me straight. > > TIA, > > /jonas > > PS mmap is a unix syscall which maps a file directly into memory > without the need to allocate memory in your program - you sort of > get access directly to the OS's file buffers which are loaded > on access of the memory via direct page-in. DS >