Here are some stats on Hatari 0.81 memory usage on Linux and what could
be done to decrease it for embedded devices.

First the binary size from "size ./hatari":
   text    data      bss       dec
1382406   10712 18255264  19648382

I.e. the binary size is 1.3MB, it has 10KB of pre-defined arrays and
18MB of non-initialized fixed size arrays.  The names of the arrays
are listed at the bottom, but STRam is the one taking 16MB.

Happily Hatari doesn't dirty (zero) all of STRam, just first 4MB
(accessible as ST ram) and 2MB at the top (used as IO-memory,
TOS and cartridge memory).  This could be optimized so that
Hatari would zero only part of the ST ram that user has configured
(e.g. 0.5MB instead of 4MB -> 3.5MB private memory save).


When I Massifed Hatari with Valgrind (valgrind.kde.org), it tells that
Hatari mallocs about 3MB of memory.  The allocations and how to make
them smaller for embedded devices (no generic way unfortunately) are:

* Set MAX_VDI_WIDTH and MAX_VDI_HEIGHT from 1024 and 768 to 640 and 400
  respectively  in includes/vdi.h, decrease memory usage from 1.5MB to
  0.5MB (btw. for page flipping Allocation 2*2 framebuffers).
  - Change list of VDI modes in Hatari dialog accordinly

* Do not load bigfont in gui-sdl/sdlgui.c, especially if the device screen
  is smaller than VGA.  Both fonts together take about 1/3 MB.

* Change uncompressed file read to use mmap() instead, currently
  memory is allocated for the whole disk image before reading it.
  - With normal DD floppy image Hatari would use that amount which
    might be acceptable, but with e.g. 2MB disk needed for running
    Wolf3D 0.8, mmap() sounds much better
  - For compressed disk images memory needs to be allocated for
    uncompressed image data, i.e. there we cannot save memory.

* Check whether the m86k instruction table could be made smaller:
        #include "uae-cpu/readcpu.h"
        printf("%d -> %d\n", sizeof(struct instr), sizeof(struct instr) * 65536);
  On x86 it's slightly over 1MB.

See also the attached Massif graph.


From /proc/sysvipc/shm one can see that Hatari shares about 200KB
with the X server.  According to Xrestop Hatari doesn't keep any image
resources at the X server side.  These cannot be made smaller.


	- Eero

To see the objects in the binary BSS section, get the datadump script
from here:
     http://live.gnome.org/MemoryReduction_2fTools

Compile Hatari without stripping, and use:
     datadump.py -n -s .bss ./hatari

As a result you see these array variables (larger ones):
16777216 STRam hatari
  321536 CyclePalettes hatari
  262144 mem_banks hatari
  262144 cpufunctbl hatari
  131072 pInterceptWriteTable hatari
  131072 pInterceptReadTable hatari
   69632 InternalDTAs hatari
   65536 EnvelopeShapeValues hatari
   53588 DialogParams hatari
   53588 ConfigureParams hatari
   19976 FrameBuffers hatari
   16384 ST2RGB hatari
    8864 HBLPalettes hatari
    8448 FileHandles hatari
    8240 EmulationDrives hatari
    8192 MixBuffer hatari
