Path: chuka.playstation.co.uk!news From: gil@snsys.com (Gil Jaysmith) Newsgroups: scee.yaroze.programming.gnu_compiler Subject: Re: Memory allocation probs... Date: Wed, 29 Oct 1997 12:03:08 GMT Organization: SN Systems Lines: 28 Message-ID: <3457247b.3906186@news.playstation.co.uk> References: <34551BB5.58BA@dial.pipex.com> <3454c596.21265918@news.playstation.co.uk> <3456076E.92B9FC58@micronetics.com> <3456FA5F.DB8@dial.pipex.com> Reply-To: gil@snsys.com NNTP-Posting-Host: gil.snsys.com X-Newsreader: Forte Free Agent 1.11/32.235 Chris Chadwick wrote: >Still, I'm a bit surprised I didn't get any kind of compiler/linker >warning if there was a problem with the two huge, static arrays in >the first place. I'm probably showing my lack of compiler knowledge, >but Im not proud (Gil, stop laughing :) I'm trying ;=) More info: if you allocate space for static arrays which aren't initialised, this space is reserved in the .bss section, which isn't saved as part of the image but is zeroed out for you when the exe is loaded. So this memory would've been claimed for you before the program started running, and the compiler and linker wouldn't have complained since they just request the space, they don't care whether it actually exists and it's left to you to pick up the pieces if it doesn't. The heap should run from the end of the user segment to the bottom of the stack space at the top of memory (you call InitHeap to tell it this). The manufacturer-supplied startup code typically does this for you by investigating the section positions and calling InitHeap for you to claim the largest amount of free ram possible. Our PSX startup code, for example, looks for the end of the .bss section and claims everything up to 32K below the end of RAM; thus you have to be careful if you accidentally deploy overlays after that as the heap will stomp all over them. - Gil