/*			       B G E T			   Buffer allocator    Designed and implemented in April of 1972 by John Walker, based on the    Case Algol OPRO$ algorithm implemented in 1966.    Reimplemented in 1975 by John Walker for the Interdata 70.    Reimplemented in 1977 by John Walker for the Marinchip 9900.    Reimplemented in 1982 by Duff Kurland for the Intel 8080.    Portable C version implemented in September of 1990 by an older, wiser    instance of the original implementor.    Souped up and/or weighed down  slightly  shortly  thereafter  by  Greg    Lutz.    AMIX  edition, including the new compaction call-back option, prepared    by John Walker in July of 1992.    Bug in built-in test program fixed, ANSI compiler warnings eradicated,    buffer pool validator  implemented,  and  guaranteed  repeatable  test    added by John Walker in October of 1995.    This program is in the public domain.     1. This is the book of the generations of Adam.   In the day that God	created man, in the likeness of God made he him;     2. Male and female created he them;  and  blessed	them,  and  called	their name Adam, in the day when they were created.     3. And  Adam  lived  an hundred and thirty years,	and begat a son in	his own likeness, and after his image; and called his name Seth:     4. And the days of  Adam  after  he  had  begotten  Seth  were  eight	hundred years: and he begat sons and daughters:     5. And  all  the  days  that Adam lived were nine	hundred and thirty	years: and he died.     6. And Seth lived an hundred and five years, and begat Enos:     7. And Seth lived after he begat Enos eight hundred and seven  years,	and begat sons and daughters:     8.  And  all the days of Seth were nine hundred and twelve years: and	 he died.     9. And Enos lived ninety years, and begat Cainan:    10. And Enos lived after he begat  Cainan eight  hundred  and  fifteen	years, and begat sons and daughters:    11. And  all  the days of Enos were nine hundred  and five years:  and	he died.    12. And Cainan lived seventy years and begat Mahalaleel:    13. And Cainan lived  after he  begat  Mahalaleel  eight  hundred  and	forty years, and begat sons and daughters:    14. And  all the days of Cainan were nine  hundred and ten years:  and	he died.    15. And Mahalaleel lived sixty and five years, and begat Jared:    16. And Mahalaleel lived  after  he  begat	Jared  eight  hundred  and	thirty years, and begat sons and daughters:    17. And  all  the  days  of Mahalaleel  were eight hundred	ninety and	five years: and he died.    18. And Jared lived an hundred sixty and  two  years,   and  he  begat	Enoch:    19. And  Jared  lived  after he begat Enoch  eight hundred years,  and	begat sons and daughters:    20. And all the days of Jared  were nine hundred sixty and two  years:	and he died.    21. And Enoch lived sixty and five years, and begat Methuselah:    22. And  Enoch  walked   with  God	after  he  begat Methuselah  three	hundred years, and begat sons and daughters:    23. And all the days of  Enoch  were  three  hundred  sixty  and  five	years:    24. And Enoch walked with God: and he was not; for God took him.    25. And  Methuselah  lived	an  hundred  eighty and  seven years,  and	begat Lamech.    26. And Methuselah lived after he  begat Lamech seven  hundred  eighty	and two years, and begat sons and daughters:    27. And  all the days of Methuselah  were nine hundred  sixty and nine	years: and he died.    28. And Lamech lived an hundred eighty  and two  years,  and  begat  a	son:    29. And  he called his name Noah, saying,  This same shall	comfort us	concerning  our  work and toil of our hands, because of the ground	which the LORD hath cursed.    30. And  Lamech  lived  after  he begat Noah  five hundred	ninety and	five years, and begat sons and daughters:    31. And all the days of Lamech were  seven hundred seventy	and  seven	years: and he died.    32. And  Noah  was five hundred years old:	and Noah begat Shem,  Ham,	and Japheth.    And buffers begat buffers, and links begat	links,	and  buffer  pools    begat  links  to chains of buffer pools containing buffers, and lo the    buffers and links and pools of buffers and pools of links to chains of    pools  of  buffers were fruitful and they multiplied and the Operating    System looked down upon them and said that it was Good.    INTRODUCTION    ============    BGET  is a comprehensive memory allocation package which is easily    configured to the needs of an application.	BGET is  efficient  in    both  the  time  needed to allocate and release buffers and in the    memory  overhead  required	for  buffer   pool   management.    It    automatically    consolidates   contiguous	 space	 to   minimise    fragmentation.  BGET is configured	by  compile-time  definitions,    Major options include:	*   A  built-in  test  program	to  exercise  BGET   and	    demonstrate how the various functions are used.        *   Allocation  by  either the "first fit" or "best fit"	    method.	*   Wiping buffers at release time to catch  code  which	    references previously released storage.	*   Built-in  routines to dump individual buffers or the	    entire buffer pool.	*   Retrieval of allocation and pool size statistics.	*   Quantisation of buffer sizes to a power  of  two  to	    satisfy hardware alignment constraints.	*   Automatic  pool compaction, growth, and shrinkage by	    means of call-backs to user defined functions.    Applications  of  BGET  can  range	from  storage  management   in    ROM-based  embedded programs to providing the framework upon which    a  multitasking  system  incorporating   garbage   collection   is    constructed.   BGET  incorporates  extensive  internal consistency    checking using the <assert.h> mechanism; all these checks  can  be    turned off by compiling with NDEBUG defined, yielding a version of    BGET with minimal size and maximum speed.    The  basic	algorithm  underlying  BGET  has withstood the test of    time;  more  than  25  years   have   passed   since   the	 first    implementation  of	this  code.  And yet, it is substantially more    efficient than the native allocation  schemes  of  many  operating    systems: the Macintosh and Microsoft Windows to name two, on which    programs have obtained substantial speed-ups by layering  BGET  as    an application level memory manager atop the underlying system's.    BGET has been implemented on the largest mainframes and the lowest    of	microprocessors.   It  has served as the core for multitasking    operating systems, multi-thread applications, embedded software in    data  network switching processors, and a host of C programs.  And    while it has accreted flexibility and additional options over  the    years,  it	remains  fast, memory efficient, portable, and easy to    integrate into your program.    BGET IMPLEMENTATION ASSUMPTIONS    ===============================    BGET is written in as portable a dialect of C  as  possible.   The    only   fundamental	 assumption   about  the  underlying  hardware    architecture is that memory is allocated is a linear  array  which    can  be  addressed  as a vector of C "char" objects.  On segmented    address space architectures, this generally means that BGET should    be used to allocate storage within a single segment (although some    compilers	simulate   linear   address   spaces   on    segmented    architectures).   On  segmented  architectures,  then, BGET buffer    pools  may not be larger than a segment, but since BGET allows any    number of separate buffer pools, there is no limit	on  the  total    storage  which  can  be  managed,  only  on the largest individual    object which can be allocated.  Machines  with  a  linear  address    architecture,  such  as  the VAX, 680x0, Sparc, MIPS, or the Intel    80386 and above in native mode, may use BGET without restriction.    GETTING STARTED WITH BGET    =========================    Although BGET can be configured in a multitude of fashions,  there    are  three	basic  ways  of  working  with	BGET.	The  functions    mentioned below are documented in the following  section.	Please    excuse  the  forward  references which are made in the interest of    providing a roadmap to guide you  to  the  BGET  functions  you're    likely to need.    Embedded Applications    ---------------------    Embedded applications  typically  have  a  fixed  area  of	memory    dedicated  to  buffer  allocation (often in a separate RAM address    space distinct from the ROM that contains  the  executable	code).    To	use  BGET in such an environment, simply call bpool() with the    start address and length of the buffer  pool  area	in  RAM,  then    allocate  buffers  with  bget()  and  release  them  with  brel().    Embedded applications with very limited RAM but abundant CPU speed    may  benefit  by configuring BGET for BestFit allocation (which is    usually not worth it in other environments).    Malloc() Emulation    ------------------    If the C library malloc() function is too  slow,  not  present  in    your  development environment (for example, an a native Windows or    Macintosh program), or otherwise unsuitable, you  can  replace  it    with  BGET.  Initially define a buffer pool of an appropriate size    with bpool()--usually obtained by making a call to	the  operating    system's  low-level  memory allocator.  Then allocate buffers with    bget(), bgetz(), and bgetr() (the last two permit  the  allocation    of	buffers initialised to zero and [inefficient] re-allocation of    existing buffers for  compatibility  with  C  library  functions).    Release buffers by calling brel().	If a buffer allocation request    fails, obtain more storage from the underlying  operating  system,    add it to the buffer pool by another call to bpool(), and continue    execution.    Automatic Storage Management    ----------------------------    You can use BGET as your application's native memory  manager  and    implement  automatic  storage  pool  expansion,  contraction,  and    optionally application-specific  memory  compaction  by  compiling    BGET  with	the  BECtl  variable defined, then calling bectl() and    supplying  functions  for  storage	compaction,  acquisition,  and    release,  as  well as a standard pool expansion increment.	All of    these functions are optional (although it doesn't make much  sense    to	provide  a  release  function without an acquisition function,    does it?).	Once the call-back functions have  been  defined  with    bectl(),  you simply use bget() and brel() to allocate and release    storage as before.	You can supply an  initial  buffer  pool  with    bpool()  or  rely  on  automatic  allocation to acquire the entire    pool.  When a call on  bget()  cannot  be  satisfied,  BGET  first    checks  if	a compaction function has been supplied.  If so, it is    called (with the space required to satisfy the allocation  request    and a sequence number to allow the compaction routine to be called    successively without looping).  If the compaction function is able    to  free any storage (it needn't know whether the storage it freed    was adequate) it should return a  nonzero  value,  whereupon  BGET    will retry the allocation request and, if it fails again, call the    compaction function again with the next-higher sequence number.    If	the  compaction  function  returns zero, indicating failure to    free space, or no compaction function is defined, BGET next  tests    whether  a	non-NULL  allocation function was supplied to bectl().    If so, that function is called with  an  argument  indicating  how    many  bytes  of  additional  space are required.  This will be the    standard pool expansion increment supplied in the call to  bectl()    unless  the  original  bget()  call requested a buffer larger than    this; buffers larger than the standard pool block can  be  managed    "off  the books" by BGET in this mode.  If the allocation function    succeeds in obtaining the storage, it returns a pointer to the new    block  and	BGET  expands  the  buffer  pool;  if  it  fails,  the    allocation request fails and returns NULL to  the  caller.	 If  a    non-NULL  release  function  is  supplied,	expansion blocks which    become totally empty are released  to  the	global	free  pool  by    passing their addresses to the release function.    Equipped  with  appropriate  allocation,  release,	and compaction    functions, BGET can be used as part of very  sophisticated	memory    management	 strategies,  including  garbage  collection.	(Note,    however, that BGET is *not* a garbage  collector  by  itself,  and    that  developing  such a system requires much additional logic and    careful design of the application's memory allocation strategy.)    BGET FUNCTION DESCRIPTIONS    ==========================    Functions implemented in this file (some are enabled by certain of    the optional settings below):	    void bpool(void *buffer, bufsize len);    Create a buffer pool of <len> bytes, using the storage starting at    <buffer>.	You  can  call	bpool()  subsequently  to   contribute    additional storage to the overall buffer pool.	    void *bget(bufsize size);    Allocate  a  buffer of <size> bytes.  The address of the buffer is    returned, or NULL if insufficient memory was available to allocate    the buffer.	    void *bgetz(bufsize size);    Allocate a buffer of <size> bytes and clear it to all zeroes.  The    address of the buffer is returned, or NULL if insufficient	memory    was available to allocate the buffer.	    void *bgetr(void *buffer, bufsize newsize);    Reallocate a buffer previously allocated by bget(),  changing  its    size  to  <newsize>  and  preserving  all  existing data.  NULL is    returned if insufficient memory is	available  to  reallocate  the    buffer, in which case the original buffer remains intact.	    void brel(void *buf);    Return  the  buffer  <buf>, previously allocated by bget(), to the    free space pool.	    void bectl(int (*compact)(bufsize sizereq, int sequence),		       void *(*acquire)(bufsize size),		       void (*release)(void *buf),		       bufsize pool_incr);    Expansion control: specify functions through which the package may    compact  storage  (or  take  other	appropriate  action)  when  an    allocation	request  fails,  and  optionally automatically acquire    storage for expansion blocks  when	necessary,  and  release  such    blocks when they become empty.  If <compact> is non-NULL, whenever    a buffer allocation request fails, the <compact> function will  be    called with arguments specifying the number of bytes (total buffer    size,  including  header  overhead)  required   to	 satisfy   the    allocation request, and a sequence number indicating the number of    consecutive  calls	on  <compact>  attempting  to	satisfy   this    allocation	request.   The sequence number is 1 for the first call    on <compact> for a given allocation  request,  and	increments  on    subsequent	calls,	permitting  the  <compact>  function  to  take    increasingly dire measures in an attempt to free up  storage.   If    the  <compact>  function  returns  a nonzero value, the allocation    attempt is re-tried.  If <compact> returns 0 (as  it  must	if  it    isn't  able  to  release  any  space  or add storage to the buffer    pool), the allocation request fails, which can  trigger  automatic    pool expansion if the <acquire> argument is non-NULL.  At the time    the  <compact>  function  is  called,  the	state  of  the	buffer    allocator  is  identical  to  that	at  the  moment the allocation    request was made; consequently, the <compact>  function  may  call    brel(), bpool(), bstats(), and/or directly manipulate  the	buffer    pool  in  any  manner which would be valid were the application in    control.  This does not, however, relieve the  <compact>  function    of the need to ensure that whatever actions it takes do not change    things   underneath  the  application  that  made  the  allocation    request.  For example, a <compact> function that released a buffer    in	the  process  of  being reallocated with bgetr() would lead to    disaster.  Implementing a safe and effective  <compact>  mechanism    requires  careful  design of an application's memory architecture,    and cannot generally be easily retrofitted into existing code.    If <acquire> is non-NULL, that function will be called whenever an    allocation	request  fails.  If the <acquire> function succeeds in    allocating the requested space and returns a pointer  to  the  new    area,  allocation will proceed using the expanded buffer pool.  If    <acquire> cannot obtain the requested space, it should return NULL    and   the	entire	allocation  process  will  fail.   <pool_incr>    specifies the normal expansion block size.	Providing an <acquire>    function will cause subsequent bget()  requests  for  buffers  too    large  to  be  managed in the linked-block scheme (in other words,    larger than <pool_incr> minus the buffer overhead) to be satisfied    directly by calls to the <acquire> function.  Automatic release of    empty pool blocks will occur only if all pool blocks in the system    are the size given by <pool_incr>.	    void bstats(bufsize *curalloc, bufsize *totfree,			bufsize *maxfree, long *nget, long *nrel);    The amount	of  space  currently  allocated  is  stored  into  the    variable  pointed  to by <curalloc>.  The total free space (sum of    all free blocks in the pool) is stored into the  variable  pointed    to	by  <totfree>, and the size of the largest single block in the    free space	pool  is  stored  into	the  variable  pointed	to  by    <maxfree>.	 The  variables  pointed  to  by <nget> and <nrel> are    filled, respectively, with	the  number  of  successful  (non-NULL    return) bget() calls and the number of brel() calls.	    void bstatse(bufsize *pool_incr, long *npool,			 long *npget, long *nprel,			 long *ndget, long *ndrel);    Extended  statistics: The expansion block size will be stored into    the variable pointed to by <pool_incr>, or the negative thereof if    automatic  expansion  block  releases are disabled.  The number of    currently active pool blocks will  be  stored  into  the  variable    pointed  to  by  <npool>.  The variables pointed to by <npget> and    <nprel> will be filled with, respectively, the number of expansion    block   acquisitions   and	releases  which  have  occurred.   The    variables pointed to by <ndget> and <ndrel> will  be  filled  with    the  number  of  bget()  and  brel()  calls, respectively, managed    through blocks directly allocated by the acquisition  and  release    functions.	    void bufdump(void *buf);    The buffer pointed to by <buf> is dumped on standard output.	    void bpoold(void *pool, int dumpalloc, int dumpfree);    All buffers in the buffer pool <pool>, previously initialised by a    call on bpool(), are listed in ascending memory address order.  If    <dumpalloc> is nonzero, the  contents  of  allocated  buffers  are    dumped;  if <dumpfree> is nonzero, the contents of free blocks are    dumped.	    int bpoolv(void *pool);    The  named	buffer	pool,  previously  initialised	by  a  call on    bpool(), is validated for bad pointers, overwritten data, etc.  If    compiled with NDEBUG not defined, any error generates an assertion    failure.  Otherwise 1 is returned if the pool is valid,  0	if  an    error is found.    BGET CONFIGURATION    ==================