Mail Archives: djgpp-workers/2003/06/16/16:14:35
Hello.
CBFalconer wrote:
>
> Richard Dawe wrote:
> >
> > I've just started looking at integrating nmalloc. CBFalconer: I have
> > a couple of problems:
> >
> > * memalign relies on <libc/malloc.h>. As I understand it, nmalloc
> > uses a different memory-block format than the current implementation.
> >
> > memalign is new in 2.04. CBFalconer, please please please check out
> > CVS! This needs fixing, before I can integrate the code. You will
> > need a CVS checkout anyway for later maintenance.
>
> I have a whole bunch of excuses: I have never used CVS, I am
> getting short of disk space, I am a crusty old fogie, I am running
> an ancient 486/80. I don't understand "memalign", where does that
> id come from? In nmalloc alignment is governed by ALIGN define.
If you can't get CVS, please get one of MartinS's CVS snapshots. You may have
to ask him to update it - last time I looked, it was stale. I sent a URL in a
previous e-mail to the list - probably in a discussion about nmalloc.
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.
> >
> > 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.
[snip]
> I have no idea on the CVS. I am perfectly amenable to changing
> such names; so far they are never used outside of the nmalloc
> package, so now is the time to change them. I envisioned that the
> library make would refer to nmalloc.c and malldbg.c and their
> dependancies, possibly also nmalloc.txh (or whatever it gets
> renamed to). I also originally envisioned stdlib.h just
> #including malldbg.h and sysquery.h in the appropriate places with
> the appropriate guards. That way there is only one place to
> modify.
>
> The existing nmalloc makefile is a mess, but suffices for
> independent modification and testing. It is obviously not going
> to be used in creating the library.
>
> Another area that may well need standardization is my convention
> for #include guards.
OK, I'll take care of renaming the files as appropriate.
I haven't looked at the include guards yet.
BTW I have very little time to spend on DJGPP at the moment (2-3 hours a week,
maximum). This is unlikely to change anytime soon.
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -