Path: chuka.playstation.co.uk!scea!sumner
From: sumner@austin.metrowerks.com (Joel Sumner)
Newsgroups: scee.yaroze.programming.gnu_compiler
Subject: Re: Memory allocation probs...
Date: Fri, 31 Oct 1997 12:20:36 -0600
Organization: Metrowerks
Lines: 165
Message-ID: <sumner-ya02408000R3110971220360001@news.scea.sony.com>
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> <34599B1E.4515@dial.pipex.com>
NNTP-Posting-Host: 198.214.227.182
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: Yet Another NewsWatcher 2.4.0

In article <34599B1E.4515@dial.pipex.com>, Chris Chadwick
<xjk18@dial.pipex.com> wrote:

>Me again (sorry!),
>
>Let me see if I've got this straight. Before I can malloc/calloc
>memory I need to call InitHeap(). OK. InitHeap() takes 2 args:
>void *head
>long size
>
>First, whats the best way to find an appropriate value for 'head',
>which is a pointer to where you want the start of heap mem to be?...


One fairly general memory organization technique would be:

<ugly ascii art follows - fixed width font required>

+----------------------------+  0x80090000      
|                            |        
|  Picture and Sound Data    |        
|                            |        
|----------------------------|<-------Link Address
|                            |        
|                            |        
|       Program Area         |        
|                            |        
|                            |        
|----------------------------|<-------bss end (linker generated variable)
|                            |        
|                            |        
|           Heap             |        
|                            |        
|                            |        
|----------------------------|<-------stack top-stack size
|                            |        
|           Stack            |        
|                            |        
+----------------------------+  0x801FFF00      

Since the picture and sound data sizes are pretty well constant, you can
put them low in memory and forget about them.You won't have to worry about
your program file growing and all of a sudden encroaching on your
picture/sound data area.  This is especially useful because you aren't
programatically loading the picture and sound data. Thus, you can't simply
"malloc()" a region that is the size of each file and then load it into
memory.  Your picture loading is probably controlled by the SIOCONS batch
file which has no knowledge of the heap positioning.

However, if you are chaning pictures and sounds around a lot, this might
cause problems if you don't carefully monitor the size of your picture data
block to make sure that it isn't extending past "Link Address".

If you position your picture data anywhere else in memory, you are subject
to other problems.  If you put it immediately after the program area, then
any increases in code size or data size will probably end up in a memory
area conflict. Thus, that approach won't work.

Another approach might be

+----------------------------+ 0x80090000 <-------Link Address
|                            |
|       Program Area         |
|                            |
|----------------------------|<-------bss end
|                            |
|                            |
|           Heap             |
|                            |
|                            |
|----------------------------|<-------stack top-stack size
|                            |
|                            |
|          Stack             |
|                            |
|                            |
|----------------------------|<-------stack top
|                            |
|  Picture and Sound Data    |
|                            |
+----------------------------+

Instead of adding graphics to the front of your program, you add it after
the stack.  Since your program data is nowhere near your picture data, you
won't get any runtime bugs that result from loading the picture data on top
of the program area.  If you made any changes to your picture data size,
you'd change your stack top address rather than the program link address.
(I assume the stack top can be specified using some the GNU compiler
option. I may be wrong).

>Now, arg 'size' is the amount of mem you want to allocate as the heap,
>specified in 4-byte units ('head' has to be a 4-byte aligned address
>as well, then?). Do I, then, have to make sure I don't allocate so
>much mem that the stack may creep down and clash with it?

It's probably best to use linker generated variables to determine this.  If
you take the stack top and subtract the stack size and the bss end address,
that will give you the max heap zone size.  Since it is 100% based on
linker variables, you'll never have to fiddle with the number.  However,
you probably should put in some sort of ASSERT in your code to make sure
that the heap size is always bigger than some threshold that you think is
appropriate for your code. (i.e. determining the min acceptable heap size
is "an exercise left to the reader"  <evil laugh>)


>And the last thing, the manual says that all of 'size' mem will not
>be available for allocation because of an 'overhead'. How much
>will this overhead be?

It depends upon the implementation of malloc.  When you call malloc(), it
allocates an area in the heap that not only contains the number of bytes
that you allocated but also a "header" that contains some information that
allows the malloc() function to determine where everything is located in
the heap zone.

thus, the heap zone consists of lots of blocks with the following format:

+-----------------+                
|                 |                
|block header     |                
|-----------------|<-------pointer 
|                 |        returned
|data block of    |        from    
|size requested   |        malloc()
|                 |        call    
|                 |                
|                 |                
|                 |                
|                 |                
|                 |                
|                 |                
|                 |                
|                 |                
+-----------------+                

Thus, the amount of "overhead" is determined by the number of malloc()
calls that you make, not the amount of data allocated.

So again, the actual loss due to headers will depend upon the
characteristics of your program.


So what does all of this mean to you as a programmer?  Not much.

1) Use the linker variables to make your heap as big as possible without
stomping on any other program segments.  Then you won't have to touch it.

2) Put guard code around all of your malloc()s

foo=malloc(size);
ASSERT(foo!=NULL);

That way, if you ever run out of memory, you'll know it in a hurry.

3) Don't worry too much about it.  After all, this isn't a multitasking
system.  You own the system.  It's not like you are going to have users
complaining that they can't run your program and Microsoft Word at the same
time because you take up too much memory in the PlayStation.  Be a hog.
Take it all. Don't worry about it unless you realistically think that your
entire program + graphics + dynamic data + stack will take up more than 1.5
Megs.

-- 
PlayStation Development Tools Dude
Metrowerks