Path: chuka.playstation.co.uk!scea!peter_alau@playstation.sony.com From: Elliott Lee Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: I can't stand it anymore! Date: Tue, 02 Jun 1998 15:51:12 -0700 Organization: Cisco Systems Lines: 43 Message-ID: <357481E0.452ABE74@netmagic.net> References: <35736b7c.12437918@news.scea.sony.com> <357479f7.106779210@news.scea.sony.com> Reply-To: tenchi@cisco.com NNTP-Posting-Host: dhcp-e-39-237.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.03 [en] (Win95; U) Jamin Frederick wrote: > > On Tue, 02 Jun 1998 03:11:44 GMT, antony.arciuolo@mail.trincoll.edu > (Antony Arciuolo) wrote: > > >I will ask the stupid question. How do you load files into main memory > >and prevent them from being overwritten by the code allocating memory? > > > > When you malloc() memory, you're adding space to the heap, which grows > up from the (static) program code. The stack, which grows down from > where you set it, is allocated from function calls and local > variables. So what most people do is this: Although I wondered about that---whether the Yaroze stack is growing downwards or upwards because the docs stated that you the area between 0x801f0000-0x801fffff was designated for stack. I would hope that for any malloc()-ing that is done, the amount of space is calculated before-hand as to not collide with the designated stack area. What I generally do is actually block off an area in my programming (not using malloc()) and make a note that it is a scratchpad area. e.g. 0x80090000-0x800b0000 is for game maps and manipulation of them. (Using #defines for this can also save a few cycles of pointer dereferencing.) > Stack (top of allowed yaroze space) > | > * > > (hope stack & heap don't collide!) > > * > | > Heap > Code (Loaded above Data) > Data (Loaded @ 90080000 and up -- bottom of allowed yaroze space) > > Jamin - e! tenchi@netmagic.net http://www.netmagic.net/~tenchi/yaroze/