* Re: Counting Elements figured out. [not found] <pan.2005.11.30.01.47.41.83657@nowhere.net> @ 2005-11-25 16:29 ` David C. Hoos, Sr. [not found] ` <pan.2005.11.30.23.15.25.917461@nowhere.net> 0 siblings, 1 reply; 4+ messages in thread From: David C. Hoos, Sr. @ 2005-11-25 16:29 UTC (permalink / raw) "Freejack" <freejack@nowhere.net> wrote in message news:pan.2005.11.30.01.47.41.83657@nowhere.net... > The title says it all. <snip> > Marker := (Size_In_Storage_Elements + Alignment - 1) / Alignment; > > Okay...32 Integers. > Storage_Unit <= 4 > Storage_Element'Size <= Storage_Unit > > Size_In_Storage_Elements <= 168 etc... > > Shouldn't it be ... Marker := (Size_In_Storage_Elements / Alignment); > ? No. The code is exactly correct; it handles cases where Size_In_Storage Elements is not evenly divisible by Alignment. Since integer division truncates, adding one less than the divisor insures that the quotient is larege enough to accommodate the fractional part, as well. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <pan.2005.11.30.23.15.25.917461@nowhere.net>]
* Re: Counting Elements figured out. [not found] ` <pan.2005.11.30.23.15.25.917461@nowhere.net> @ 2005-12-02 23:09 ` Robert A Duff 2005-12-03 22:04 ` Gisle Sælensminde 0 siblings, 1 reply; 4+ messages in thread From: Robert A Duff @ 2005-12-02 23:09 UTC (permalink / raw) Freejack <freejack@nowhere.net> writes: > Aha. I gotcha. I suppose I should take that into account when mapping the > storage space into my process. I just tested it out. It works when the > compiler does it's malloc() allocations, but segfaults on an mmaped() > region. So the length of the region I map should be > Size_In_Storage_Elements + 1, yes? And then use the " - 1 " on allocations > from that region? I don't really understand the above, but it doesn't look right. Anyway, mmap requires page-alignment, right? That is, you can't mmap 100 bytes; you have to round it up to 2**12 or 2**13 bytes or some such. > I suppose I should have two Region types. One where Storage blocks are > exact multiples of Storage_Unit, and one that handles truncated Sizes. I don't think that makes sense. Allocation is always done in integer numbers of storage units (storage elements). A storage pool type never has to deal with fractional storage elements. That is, on a normaly 8-bit-byte-addressable machine, Allocate will never be asked to allocate 3 bits, or 67 bits -- it doesn't get sizes in bits at all. You have to deal with different alignments, though. The required alignment is passed in to Allocate. It should make sure that the address returned is aligned to that boundary, or else it should raise an exception for unsupported alignments. Alignment is also in terms of storage units/elements, not bits. The simplest thing is to always align to the most stringent natural alignment required by the hardware, which is usually Long_Float'Alignment, which is usually 4 or 8. >... Oh > gawd, about two dozen possible schemes just jumped into my head all at > once. > > Heh. The wonderful world of memory managment. - Bob ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Counting Elements figured out. 2005-12-02 23:09 ` Robert A Duff @ 2005-12-03 22:04 ` Gisle Sælensminde 2005-12-03 22:21 ` Robert A Duff 0 siblings, 1 reply; 4+ messages in thread From: Gisle Sælensminde @ 2005-12-03 22:04 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> writes: > Freejack <freejack@nowhere.net> writes: > > > Aha. I gotcha. I suppose I should take that into account when mapping the > > storage space into my process. I just tested it out. It works when the > > compiler does it's malloc() allocations, but segfaults on an mmaped() > > region. So the length of the region I map should be > > Size_In_Storage_Elements + 1, yes? And then use the " - 1 " on allocations > > from that region? I would think that allocation Size_In_Storage_Elements + 1 will give one byte to much for the underlying file (unless it's an annonymous map). Then mmap will return without error, but the process will be recieve a bus error if the last byte is accessed. > I don't really understand the above, but it doesn't look right. > > Anyway, mmap requires page-alignment, right? That is, you can't mmap > 100 bytes; you have to round it up to 2**12 or 2**13 bytes or some > such. The mmap call will allocate in blocks, but it will always allocate at least as much as you ask for, so it's no problem to map 100 bytes with mmap. It is more likely that the OP did not set the mapped pages to be readable or writable, or that the file was actually shorter than the number of bytes asked for. This (and more) will cause mmap to return "successfully", but the process will fail when the memory is accesed. It's far fewer things that can go wrong with malloc. In fact malloc may also have this blockwise allocation property on many systems. -- Gisle Sælensminde, Phd student, Scientific programmer Computational biology unit, BCCS, University of Bergen, Norway, Email: gisle@cbu.uib.no ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Counting Elements figured out. 2005-12-03 22:04 ` Gisle Sælensminde @ 2005-12-03 22:21 ` Robert A Duff 0 siblings, 0 replies; 4+ messages in thread From: Robert A Duff @ 2005-12-03 22:21 UTC (permalink / raw) gisle@apal.ii.uib.no (Gisle Sælensminde) writes: > The mmap call will allocate in blocks, but it will always allocate at least > as much as you ask for, so it's no problem to map 100 bytes with mmap. > It is more likely that the OP did not set the mapped pages to be readable or > writable, or that the file was actually shorter than the number of bytes > asked for. This (and more) will cause mmap to return "successfully", but > the process will fail when the memory is accesed. It's far fewer things > that can go wrong with malloc. In fact malloc may also have this > blockwise allocation property on many systems. If you don't want to bother with files at all, which is likely, you can mmap /dev/zero. - Bob ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-12-03 22:21 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <pan.2005.11.30.01.47.41.83657@nowhere.net> 2005-11-25 16:29 ` Counting Elements figured out David C. Hoos, Sr. [not found] ` <pan.2005.11.30.23.15.25.917461@nowhere.net> 2005-12-02 23:09 ` Robert A Duff 2005-12-03 22:04 ` Gisle Sælensminde 2005-12-03 22:21 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox