Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: Ed Federmeyer <fedeedw@charlie.cns.iit.edu>
Newsgroups: scea.yaroze.programming.codewarrior
Subject: Re: Initializing the heap
Date: Thu, 30 Oct 1997 23:02:17 -0600
Organization: (no organization)
Lines: 45
Message-ID: <34596659.40D5@charlie.cns.iit.edu>
References: <01bce566$fdb8c1a0$a5bf43ce@wkwerner>
Reply-To: fedeedw@charlie.cns.iit.edu
NNTP-Posting-Host: charlie.cns.iit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0C-GZone  (Win95; I)

Wayne K. Werner wrote:
> 
> Say what?!
> 
> What's this about initializing the heap in main?  I don't believe
> that the GNU users have to do that.  It's a common detail, part of
> the setup of just about any non-trivial program, full of
> magic numbers, that belongs in the startup code!
> And this makes CW code incompatable with GNU, without some further
> #pragma crap.

Actually we GNU users "need" to do it too.  I say "need" in
quotes, because it seems you can usually seem to get away with
doing a few small mallocs, without initializing the heap, but if
you do anything serious, it will soon fail.  Or crash.  You
never can tell.  All of my "mysterious" problems started when I
began using malloc in earnest, and went away when I started taking
care to initialize the heap!

One problem with putting it in the startup code is "how does it know
how much heap space to manage".  Every project has different
dynamic memory needs, from "none" to 1Mb or more! (ie, tiny code,
huge data!)

> As for me, I think I will look into modifying the startup code to put
> this back where it belongs.  I will post further after I investigate
> for anyone else who wants to do the same.

I wound up just putting it in at the begining of my main, and it's only
one line of code.  We already "need" to manually keep track of where
TIM,
TMD, VAG, etc data is loaded in memory, so it's only one more detail.

You know-  A nice tool (hint-hint to whoever likes writing tools!)
would be like the TIMUTIL/TIMTOOL that shows a graphical
representation of the video buffer, and where each of the TIMs and
double-buffers fit.  But make this one show where all the TIMS, VAGS,
etc fit into main memory, and generate a "memmap.h" header file to
be included in all relevant .c files.  It could also keep a
"PROG_START_ADDR" consistant between the makefile and the memmap.h,
so that You'd even see where your code image will load.  Anyone?  I'd
be happy to help spec it out!  :-)  I'm kind of doing that manually
now with a whiteboard!  :-)

EdF