Path: chuka.playstation.co.uk!news From: James Russell Newsgroups: scee.yaroze.programming.gnu_compiler Subject: Re: Memory allocation probs... Date: Thu, 30 Oct 1997 10:32:21 +1300 Organization: Peace Computers NZ Ltd Lines: 55 Message-ID: <3457AB65.28CC@peace.co.nz> References: <34551BB5.58BA@dial.pipex.com> <3454c596.21265918@news.playstation.co.uk> <3456076E.92B9FC58@micronetics.com> <3456FA5F.DB8@dial.pipex.com> <345695E0.6102@peace.co.nz> <3457216F.61478ECA@micronetics.com> NNTP-Posting-Host: intro.peace.co.nz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0Gold (X11; I; IRIX 6.2 IP22) Jim wrote: > > The stack starts at the last 4 bytes of memory (0x801ffffd) and works it > way down. > > I load all data starting at 0x80090000 and link my code to run at > 0x80100000. The psx kernel ends at 0x80090000. > > You have to be cautious when loading data after your code and programs > data segments (anything > 0x80100000) because the BSS segment is > located past the end of the program but is not actually located within > the program binary when you upload it. > Use the 'size' command on your program to see how large it really is. > It's quite possible for your program to knob over your data file at > runtime if they are located too close to the end of your code or static > data. It also means that you could start getting spurious errors as > your data files get trolleyed. > > Malloc etc grabs memory from the heap. This is located wherever you > tell it with the InitHeap command. This is different under codewarrior, > look at the startup stub for codewarrior to see how they do this. > > I now compress all my data files to speed upload times, but I still > think I have to exceed the 0x80100000 limit for data. I guess it depends on your application - if it's just a program that loads the TIMs/VAGs into memory and never needs to reload them then I would prefer my way (link to 90000, data at 100000) - That way my program resides just above kernel, so no space is wasted, and the only thing I've got to worry about is if the BSS section will overrun 100000. The trick is NOT to have a BSS section (ha!), or to mung the startup code to shove your TIMs/VABs into VRAM/SRAM before BSS is initialised. And I don't want to even think about doing that. If I was writing a professional game with CD access instead of SIOCONS, I would put my code as low as possible. It's possible to determine the size of the code (incl. BSS), and you know that is static, so leave all the memory above for TIM loading and memory. To split that into two (load area BELOW code, malloc area ABOVE) seems inefficient and a waste of precious resource. But I'm being pedantic. Just out of interest, how big is the kernel for a normal commercial game? We effectively have 1.5 MB to work with, how much do the pro's get? I've been playing Abe's Oddysee for the last few days, and I'm wondering how they managed to get all that graphics data in there! :O) J -- ==PEACE COMPUTERS ==James.Russell@peace.co.nz - 64(9)3730400 -Fax 64(9)3730401 Make like a shepherd and get the flock out of here.