Mail Archives: djgpp-workers/2003/06/16/21:15:28
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 <stdlib.h>
>
> 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
> > > <libc/malloc.h>? Or should <libc/malloc.h> become an empty
> > > header? (It seems to me like the block format should go in
> > > <libc/malloc.h>.)
> >
> > 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.
>
> <libc/malloc.h> is an internal library header. If we reimplement
> memalign using nmalloc, then we may need to replace the current
> <libc/malloc.h> 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.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -