Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: sumner@metrowerks.com (Joel Sumner) Newsgroups: scea.yaroze.programming.codewarrior Subject: Re: System memory Date: Wed, 23 Jul 1997 15:44:46 -0500 Organization: Metrowerks Lines: 50 Message-ID: References: <01bc957d$ffb78880$9fbf43ce@wkwerner> <33d63ee2.2608036@news.scea.sony.com> NNTP-Posting-Host: jsumner2.metrowerks.com X-Newsreader: Anawave Gravity v1.10 In article <33d63ee2.2608036@news.scea.sony.com>, jamin1@psu.edu says... > On 21 Jul 1997 02:30:13 GMT, "Wayne K. Werner" > wrote: > > >Jamin Frederick wrote > >Even though the stack is placed as high as possible, you are not safe. As > >far as I can tell, there is no stack checking. That's correct. Unless you have a protected memory OS (like Windows, Unix, etc..) it's difficult to reliably check stack overrun. About the best thing you can do is put a known pattern in memory just below the "bottom" of the stack (stackaddr-stacksize) and periodically check to see if that pattern ever changes. Of course, if your heap gets corrupted by the stack, the program may crash before you get back to your stack- checking routine. > 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? I mean, the estimations of the > actual program's stack and heap is all left up to the programmer? And > if so, how does the programmer make such estimates? The values in the linker panel only affect the linker variables. We use those variables in _psstart.c to set up the heap and the stack, but you can mess with them in any way you like. The heap is typically the area from the end of your program (code+data+small data+uninitialized data) to the bottom of your stack (stackaddr-stacksize) > One more thing, I got a link error when trying to port my tank > project. It said > > "Link Error : ndefined: ‘__cvt_fp2unsigned’ > eferenced from ‘mUpdateScreen’ in update.c" > > I have been using some floating point calculations, so I suspect this > is the issue. Perhaps this is prompting me to start doing some fixed > point (floating point isn't supported in CW)!!! Anyway, is floating > point the problem? Yes. The version of the compiler that was shipped in the patch does not support floating point emulation. A compiler with this capability is currently in testing. -- ------------------------- PlayStation Debugger Dude Metrowerks