Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: "Wayne K. Werner" <wkwerner@con2.com>
Newsgroups: scea.yaroze.programming.codewarrior
Subject: Re: System memory
Date: 6 Aug 1997 22:40:17 GMT
Organization: SCEA Net Yaroze News
Lines: 78
Message-ID: <01bca2b9$a16f32c0$69bf43ce@wkwerner>
References: <01bc957d$ffb78880$9fbf43ce@wkwerner> <33d63ee2.2608036@news.scea.sony.com>
NNTP-Posting-Host: port05.con2.com
X-Newsreader: Microsoft Internet News 4.70.1155

I wrote the following:

>Perhaps you would be better served by placing the program at the default
>80090000 and find the end of the program (generate the map when linking
and
>look at the value of the linker defined variable _end).  It seems that
>between 80090000 and _end is contained all of the code and data of all
>types, including the heap.  There is a linker variable called _heap_size
>with a value of 0x400.  A paltry amount for the heap!
>...
>However, the
>point is that _end points to the beginning of all *unused* space after
your
>program.  You can load tims, or anything else for that matter, into this
>space to your hearts delight!
> 
Alas, in light of new info found in this thread, I see how wrong I was.  

First, the stack size is in KBs, which means that the default size is 1MB. 
And the heap is not safely ensconced under the _end address value, but
starts there, growing up.  This indeed puts your data between a rock and a
hard place, the heap and the stack, if you should use the method I outlined
above.

It seems to me that the method Jamin had stated, putting the data below the
program, is the safest way to go... maybe (see below).
>
> 	Sorry, but how does stack checking work?  Is it a way to
> prevent collision, and if so, how?  Or is it just a means to see if
> you're "playing it on the edge", as you say.
> 
The easiest form of stack checking I can see for the NY is to run your
program in debug mode, stepping into each routine to the depth desired.  Do
a register dump to see what the value of the stack pointer is.  It will
have the address of the next location to be used for the next push.  By
comparing this with (_end + _heap_size), you should have a fairly good idea
of what the stack is doing.  You could also insert the above check into a
function to fprint the value at various points in your code or a macro to
do an assert type report and abort (enable and disable this with a stack
check #define).
This type of check, although not fool proof could prove quite useful.

> 	As far as changing the linker variables _stack and _heap,
> though, does this just mean the maximum that will allow for your stack
> and heap, so that if your actual stack and heap DO overflow these
> values, there's no accounting for it?

As far as the stack goes, there is no built in language mechanism for
checking the stack.  As far as the heap goes, a return of NULL by allocs
(new) when the heap is full is supposed to be the rule.  (Any of you MW
guys know if this is the case?)

Finally, I still think a variation of what I stated previously still holds
as a powerful reason to keep your default program start address at
80090000.
If the heap is set to a particular size comfortable for your program, then
the value (_end + _heap_size) should point to *unused* space, perfect for
loading that pesky data in on the fly.

This is very handy for much of the video data (tims and tmds) which are
loaded into main memory just so their data can be transfered to video
memory and then never used again!  Wow, lotsa dead space could be reclaimed
by reusing this memory.

OUCH! Just had a flash.  You could play the same game with the heap as you
could with this *unused* memory!

Anyhow, this would of course slow down program loading considerably
compared to the load data once, program many scenario.  TANSTAAFL! (Any
Niven fans out there?)

While I'm at it, does anyone have any examples or knowlege on how to pull
off the on the fly trick?  Does the software have to be running under the
CW debugger to do it?
-- 
Wayne K. Werner
wkwerner@con2.com