Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!uwvax!daffy!cat9.cs.wisc.edu!schaut
From: schaut@cat9.cs.wisc.edu (Rick Schaut)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Need help with Turbo C "farmalloc"
Keywords: Turbo C farmalloc
Message-ID: <4288@daffy.cs.wisc.edu>
Date: 13 Feb 90 12:47:20 GMT
References: <4100@mace.cc.purdue.edu>
Sender: news@daffy.cs.wisc.edu
Organization: U of Wisconsin CS Dept
Lines: 38

In article <4100@mace.cc.purdue.edu> afc@mace.cc.purdue.edu (Greg Flint) writes:
| I've been trying to use the "farmalloc" routine with Turbo C 2.0.  I am
| trying to allocate numerous small units (e.g., 6 - 20 bytes with each
| call).  I don't know the number or size of the units in advance -- it is
| data dependent -- so I can't use "farcalloc".
| 
| The problem that I'm having is that when I request 1-8 bytes, I'm given
| 16.  When I request 9-16, I'm given 32 bytes...and so on.  This causes
| me to run out of memory long before I should.  (This is determined by
| calling "farcoreleft" after each "farmalloc" call.)

Farmalloc, unlike malloc, needs to let DOS know that it is allocating a
block of memory (the far heap is not allocated at load time).  Thus it
makes a call to function 48h of the DOS 21h interrupt.  Quoting from
Peter Norton's "Programmer's Guide to the IBM PC and PS/2":

	Function 48h (decimal 72) dynamically allocates memory.  You request
	the number of paragraphs (16 byte units) you want allocated in BX.
	On return, AX contains the segment of the allocated memory block.
		p374

Remember also that TC needs to add 8 bytes of overhead (4 bytes for the
size of the block + 4 bytes for a pointer to the next block) to enable
garbage collection.

| Does anyone have a patch or a code around for this problem?  I know that I
| could do one big "farmalloc" and write my own "little malloc", but speed
| is important and I'd prefer not have to execute "C" code if assembler code
| (or a patch) is available.  Besides, writing "little malloc" seems a lot
| like re-inventing the wheel.

The only thing I can think of is compiling to the compact memory model, and
using malloc.  However, you may be subject to the same problem.

--
Rick (schaut@garfield.cs.wisc.edu)

Peace and Prejudice Don't Mix! (unknown add copy)