Message-ID: <3EEE3821.2C04E9D4@yahoo.com> Date: Mon, 16 Jun 2003 17:35:29 -0400 From: CBFalconer Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: nmalloc integration issues: memalign, names References: <3EECBA0F DOT 9D6D4B30 AT phekda DOT freeserve DOT co DOT uk> <3EECD63E DOT 19C52226 AT yahoo DOT com> <3EEE24E7 DOT E7B03AB0 AT phekda DOT freeserve DOT co DOT uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Richard Dawe wrote: > CBFalconer wrote: > > Richard Dawe wrote: > > > ... snip ... > > >From src/libc/compat/stdlib/memalign.txh: > > @node memalign, memory > @findex memalign > @subheading Syntax > > @example > #include > > void *memalign(size_t size, size_t alignment); > @end example > > @subheading Description > > This function is like @code{malloc} (@pxref{malloc}) except the returned > pointer is a multiple of @var{alignment}. @var{alignment} must be a power of > 2. > > @subheading Return Value > > A pointer to a newly allocated block of memory. > > @subheading Portability > > @portability !ansi, !posix > > @subheading Example > > @example > char *page = memalign(1024, 1024 * 4); > @end example > > I don't think it would be hard to implement. I'd do it myself, > except that I can't contribute any code at the moment, because > I need a disclaimer from my new employer. Not that easy. You can't just grab a block and then discard a portion, because the resultant pointer could not be passed to free. Even if we get past that with special access to nmalloc internals, any realloc would lose the alignment. That can be covered by a special "reallocalign" which goes through a complete malloc/copy/free cycle, and thus loses the advantages of the nmalloc realloc, which avoids copying as far as possible. I don't remember seeing any mention of it here. I am very leery of saying I can do anything now, because I expect to be taking off for a couple of months shortly. I can see my way to implementing it within nmalloc, though, if it doesn't need a special realloc. With my systems hat on I can see the utility of a memalign operation, but why for DJGPP? Those low level abilities (e.g. paging) are all handled within Windoze anyhow or are not needed under other OSs. In fact, without tying to actual (non-virtual) addresses it seems pretty pointless to me. Does sbrk(0) return the current top? If so sbrk(amount+delta) could saw off such pieces without any dependance on malloc or nmalloc. The only penalty would be wastage and a future unexpected sbrk result in nmalloc. Just some thoughts. > > > > > > > What should we do with the new block format? Put it in > > > ? Or should become an empty > > > header? (It seems to me like the block format should go in > > > .) > > > > If I understand you correctly, you are referring to the internal > > structure of allocated blocks. That is what sysquery is for - it > > exports the details, so things can dynamically adapt to any > > changes in nmalloc. Outside of debug version, the only external > > things nmalloc needs is the prototypes for malloc, free, realloc, > > and sbrk. The usage in malldbg and the macros therein illustate > > accessing everything. > > is an internal library header. If we reimplement > memalign using nmalloc, then we may need to replace the current > with an nmalloc-ish version. This may just be the > name of an internal function that allocates on an arbitrary size > boundary, which memalign can then call. It may be better to extend the sysquery mechanism, so nothing needs to know about it. As long as I add a field after the existing fields, everything remains compatible. Somewhere there needs to be a type definition for the added function. I shall mull this. -- Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net) Available for consulting/temporary embedded and systems. USE worldnet address!