ARM Club 3/TheARMClub_PDCD3.iso/hensa/misc/tornado/easy001/2

Text File | 1995-07-23 | 4KB | 75 lines

Memory management
-=-=-=-=-=-=-=-=-

Tornado manages its memory, and the memory of the apps until its control much
differently from convention.
   The application image is stored in its wimpslot, along with any internal
data. Due to RPC restrictions, the wimpslot may not exceed 16Mb in size.
   All files loaded into tornado apps are stored in a heap located in the
RMA. This heap's blocks are relocatable, and the heap is garbaged regularly.
Any free space is returned immediately to the RMA.

The reason why files are kept in RMA, is because:
 (a): On every architecture, the RMA is infinite in length. This allows files
of infinite length to be loaded obviously.
 (b): Virtual memory techniques can be applied to data in RMA, whereby blocks
(being relocatable) can be dumped to disc and copied back in when needed (i)
 (c): The files are at the full reach of Tornado, and so can be accessed
wihout the owning task's permission. Obviously tornado apps must keep a copy
of the file in a saveable format at all times - if this is not possible, the
task must provide a routine to generate a saveable file. Of course, _no_ task
actually owns any files loaded into torando apps - except Tornado itself.
   Advantages of this system of centralising files:
        - Saves and insertion are/can be automated
        - OLE and hotlinking can also be automated
        - Convertors can be used to translate between formats. For example,
if the user drags a GIF file to a Tornado app that can only accept Sprites,
it gets converted first and dumped into tfs: to be loaded in. Being saved
back, it get converted back. This is done by a specialised range of subtasks
(see the appropriate docs)
        - Upon your app crashing, files currently being edited can
automatically be saved out. This of course can only be done if your app
maintains a ready-to-save copy of the file at all times (which is
recommended). (See appropriate docs)
        - You can use the Tornado renderers. These centralised renderers take
a file, in its saved format, and render it. They can render 2d vectors, text,
DTP pages, sound, 3d vectors, bitmaps, soundtrackers, movies - whatever. Once
a renderer is written and installed, it's available for all apps that can
take it (see appropriate docs)
        - You can use the Tornado multiprocessors. Although these are far
more generalised than just for this one, these can convert between file
formats (as mentioned above), but can also do complex tasks eg; rotate a
JPEG. This may be done not only on a local processor, but perhaps on a second
processor or a processor on a machine on the other end of a network see
appropriate docs)

(i): Virtual memory works by breaking up very long block into much smaller
ones (usually a multiple of the track size of the disc media upon which the
cache is being kept for speed). Each of these blocks has a time associated
with it (OS_Monotonic) ie; when it was last accessed using Tornado_Getaddr.
When necessary, blocks past a certain age get dumped to disc and it is stored
where they are (disc pathname). This allows a 2560x2048 32 bit sprite (taking
normally 20Mb) to be edited on a 1Mb machine, as given that there would be an
average 75 byte header, and with 2048 blocks of 10240 bytes each (=2 tracks
on floopy E format) = about 170k of memory + 10240 to store each block.

The common tornado heap help in RMA is a special tornado heap, and is
referenced by passing 0 as the heap start to the Tornado heap SWIs. It
features relocatable blocks with auto-garbaging, and fixed blocks are
supported too. Heaps are also relocatable, so you can have a heap in a heap.
Also, heaps can be auto-extending, ie; they will increase/decrease the
allocation of whatever they are stored in. In the case of postslot heaps,
they will automatically call Wimp_SlotSize to alter the size of the heap.
This makes setting up postslot heaps extremely easy.
   Blocks in these special heaps are referenced by their handle, a negative
number. This handle is passed to all heap operations, and the program need
not worry where the data is really stored. When it needs to access the data,
it calls Tornado_Getaddr, which returns the current address of that block.
Fixed blocks are referenced a la OS_Heap style.

Another heap used by Tornado is the subtask heap, referenced by 1 - but this
is for the exclusive use of subtasks - see the appropriate documentation.

Memeory management with Tornado is something you will never have to fret
about again.