Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: jamin1@psu.edu (Jamin Frederick) Newsgroups: scea.yaroze.programming.codewarrior Subject: Re: System memory Date: Wed, 23 Jul 1997 17:59:10 GMT Organization: SCEA Net Yaroze News Lines: 122 Message-ID: <33d63ee2.2608036@news.scea.sony.com> References: <01bc957d$ffb78880$9fbf43ce@wkwerner> NNTP-Posting-Host: nb6ppp250.cac.psu.edu X-Newsreader: Forte Free Agent 1.11/32.235 On 21 Jul 1997 02:30:13 GMT, "Wayne K. Werner" wrote: >Jamin Frederick wrote > >> Speaking of memory, I've been sticking all my stuff at >> 0x80090000. This is the bottom of what we get to use. This grows >> upward with picture and sound data and stuff until it hits >> something...but what's up there, the program stack? I don't know >> what's going on up there towards the top of the mapped main >> memory...the top of main memory, according to the manual, is >> 0x801fff00. You can tell your compiler to put the program at, say, >> 0x801e3000. But this gets loaded upwards, starting at 0x801e3000, up >> to the top 0x801fff00 (adjust this according to your executable size). >> So your program stack grows downwards from 0x801e3000, until it hits >> data? >> What about the resident "bricks" loader program...where's that stored? >> >Hey, Jamin. > >Thanks for the one sprite program. I've been fiddling with it, and it has >been very helpful. Sure. There's a few typos I have to fix. Some of them might get confusing. >In porting your demo over to CW, I ran into some >problems that got me looking into the above memory issues. CW, by default >sets the program start address at 80090000. I see that you were loading >the tim data there. I guess that you have been setting the load address of >your program to a value above all of your needed data. > >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! I have yet to find a >linker flag to change this value. (Any MW people lurking?) 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! ... >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. 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. >Yup, get too recursive, or >load too much data into that *unused* space, and you will be colliding with >your stack. A painful thing indeed! When debugging a program, you might >want to occassionally look at the stack pointer to see if you are playing >on the edge or not. Maybe stack checking could be writen into the linker >startup code when a debug switch is set? > I started messing around with CW again, and did as you said. I believe that the heap size and stack size may be changed under Edit/NY Debug Settings.../Target/MIPS Project. I tried it with "one sprite" and looked at the map file, and it changed those linker variables. Is there a particular reason to load the executable at 80090000 as default rather than higher in memory? My reasoning was that in a project, your data is pretty much fixed, I mean, you probably know the extent of the data you will include in your project, such as sound, graphics, and objects. Once you load this at the bottom 80090000, you can set your code right above, so that you have maximum expansion upwards for heap, if you're adding more static code as you continue coding your project, which is what has been happening with me. I've been adding more and more globals (perhaps indiscriminantly, I must admit). And since the stack is starting at 801FFF00 (at least according to the manual and not the 801FFFFF that the Metrowerks guys think) and growing downwards, this gives you nothing to worry about in terms of static data and the stack colliding at least for a while. At that point, though, you'll be maxed out of memory anyway, so you'll be forced to change your static allocation or take it easy on the stack pushing. (Or perhaps actually doing away with some of the graphics/sound/object data, which will mess everything up). Does this seem logical? 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? >God, I love a good geeky dialog on system memory layout! Right on! >PS: The bricks stuff sits below 8090000, along with the rest of the NY >stuff loaded from the NY boot disk, I believe! Ok. So that's part of "System area". Sony's real *descriptive* with this stuff, you know? 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? Jamin