🚀 go-pugleaf

In article <1792@uwmacc.UUCP> plutchak@vms.macc.wisc.edu writes:
>In article <816@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>>All GEMDOS programs are started with the largest block of OS memory 
>>allocated to them...  The point is that your
>>program has probably been allocated ALL of free memory.  In order to
>>make memory available for a child process, you have to SHRINK the
>>block you own, returning the top part of it to GEMDOS.  The time to
>>do this is when you start up.
>
>   Does anybody know exactly how I do this using Lattice C?  The documentation
>(for version 3.04) is less than clear on this point, and everything I've
>tried hasn't worked.  I have never really *needed* to give the extra 700K
>or so of memory back, but the sheer wastefulness of it annoys me (:-), and
>someday I may want to use that memory.  I'd appreciate any pointers on the
>subject.
>   And while I'm asking advice on Lattice C, is there any special startup
>module needed to link a program used as a desk accessory, as there
>(apparently) is with other C's?
>--
>  Joel Plutchak


The Lattice C compiler is a different story. When the Metacomco guys wrote their
memory management on top of the *not perfect* memory allocation mechanism
that GemDos offers they made it static. I.e., When  a Lattice program starts
it does a shrink only for the amount:

	available - ( (_memneed)L + (_stksiz)L )

When you write a program that needs to execute the Pexec GemDos call you have
to find out how much memory your program requires during its run. Watch out:
The memory allocation mechanism from the Lattice C library (malloc and the
like) all work in the heap that is _memneed bytes large. As soon as your
program requests more than _memneed it will break. Hence you must know how
much heap space your program will need.

You will need a malloc that allows you to request memory from the system, not
a malloc that gives yu a chuck from a pool that was requested from the
system during program startup. Such a malloc would request blocks from GemDos
using trap#1 call Malloc of about 16 kbytes. (If you request 10 bytes a time
using Malloc from GemDos the 40 folder bug will turn out to be a 2 folder
bug).


If you want I could post a primitive set of memory allocation routines that
work on 520's 1040' and Mega4's