Mail Archives: djgpp-workers/2002/04/21/22:42:31
Richard Dawe wrote:
>
> CBFalconer wrote:
> [snip]
> > <http://cbfalconer.home.att.net/download/nmalloc.zip>
> [snip]
> > The realloc performance is, to my mind, quite serious. So I am
> > once again urging people to take a good look and possibly
> > incorporate it in 2.04.
>
> I've taken a look at the code now. Most of my comments are about coding style
> - please don't take offence!
>
> * I think you could use inline functions rather than macros in some cases. I
> think macros are evil, but sometimes necessary. Using inline functions would
> make debugging/examination easier. One advantage of using real functions for
> the debugging printf's is that you can get gcc to check the arguments you
> pass. Also perhaps you could also use 'const int' instead of #defines
> sometimes.
None taken. However there are really very few macros outside of
the debugging code, and definition of NDEBUG removes virtually all
of that. Those macros were designed to work with DJGPP and GCC,
not to disturb the flow of the code, and to serve as commentary
when disabled. They depend on GCC extensions. For various
reasons I do not want to go past 2.953, so can't use C99 macros.
Outside of that, looking at my source quickly, I see #defines for
MEMBLKp(p) and PTR(m), which convert between user level and
internal usage pointers, ALIGN, ALIGNMASK, MINSAVE, NONE,
DATAOFFSET. NONE is a non-NULL used to end free space lists. The
others are calculated from the fundamentals. NFLISTS is based on
sizeof(size_t) rather than pulled out of a hat, and MINSBRK is
purely arbitrary. After that I think the only macros are ISFREE
and FOULED used in checking for user level screwups.
If you look at the output of the xref you will find 4 uses of
inline, which were selected after some actual consideration.
>
> * You have a description:
>
> typedef struct memblock {
> struct memblock *prev;
> struct memblock *next;
> /* An allocated block has the next two fields NULL */
> /* A free block has them both non-NULL */
> ulong sz; /* of this memblock */
> struct memblock *nextfree;
> struct memblock *prevfree; /* actually data w/SAVEMEMORY */
> ...
> } memblock, *memblockp;
>
> Should the comment proceeding 'ulong sz' be on the line after 'sz'?
You are correct. This is a leftover from 24 byte overhead, when
there were guard areas to protect against off-by-one index
errors. "prevfree" doesn't exist in allocated memory, and
nextfree is the only normally null pointer in allocated storage.
I changed the order of components to improve the robustness under
those off-by-ones.
>
> * I think the name for the structure returned by _sysmalloc - _sysquery - is
> too generic. Why not call it _sysquery_t? Or is _sysmalloc an API used by some
> other libc that we want to be compatible with?
I have no problems with such things - however I had to hang a name
on it in order to test it. You may notice it is used in the test
driver.
>
> I can't really comment on the effectiveness of the algorithm. I guess the
> proof is in the pudding, as they say. I agree with Charles that some
> real-world benchmarks would be helpful.
The algorithm is simple - a linked list in memory order. No list
searches. Thus every operation is O(1). All else is frills and Q
of I.
I put a whole bunch (of benchmarks) up earlier using a/b
comparisons on my machine with some of my software. I am
impressed by the apparent NIH syndrome, and am not especially
motivated to contribute further efforts. This is the first time
anyone has shown any signs of even reading the code
>
> Thanks, bye, Rich =]
>
> --
> Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
--
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 -