home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / t / tornado / Easy001 / 2 < prev    next >
Encoding:
Text File  |  1995-07-23  |  4.4 KB  |  75 lines
  1. Memory management
  2. -=-=-=-=-=-=-=-=-
  3.  
  4. Tornado manages its memory, and the memory of the apps until its control much
  5. differently from convention.
  6.    The application image is stored in its wimpslot, along with any internal
  7. data. Due to RPC restrictions, the wimpslot may not exceed 16Mb in size.
  8.    All files loaded into tornado apps are stored in a heap located in the
  9. RMA. This heap's blocks are relocatable, and the heap is garbaged regularly.
  10. Any free space is returned immediately to the RMA.
  11.  
  12. The reason why files are kept in RMA, is because:
  13.  (a): On every architecture, the RMA is infinite in length. This allows files
  14. of infinite length to be loaded obviously.
  15.  (b): Virtual memory techniques can be applied to data in RMA, whereby blocks
  16. (being relocatable) can be dumped to disc and copied back in when needed (i)
  17.  (c): The files are at the full reach of Tornado, and so can be accessed
  18. wihout the owning task's permission. Obviously tornado apps must keep a copy
  19. of the file in a saveable format at all times - if this is not possible, the
  20. task must provide a routine to generate a saveable file. Of course, _no_ task
  21. actually owns any files loaded into torando apps - except Tornado itself.
  22.    Advantages of this system of centralising files:
  23.         - Saves and insertion are/can be automated
  24.         - OLE and hotlinking can also be automated
  25.         - Convertors can be used to translate between formats. For example,
  26. if the user drags a GIF file to a Tornado app that can only accept Sprites,
  27. it gets converted first and dumped into tfs: to be loaded in. Being saved
  28. back, it get converted back. This is done by a specialised range of subtasks
  29. (see the appropriate docs)
  30.         - Upon your app crashing, files currently being edited can
  31. automatically be saved out. This of course can only be done if your app
  32. maintains a ready-to-save copy of the file at all times (which is
  33. recommended). (See appropriate docs)
  34.         - You can use the Tornado renderers. These centralised renderers take
  35. a file, in its saved format, and render it. They can render 2d vectors, text,
  36. DTP pages, sound, 3d vectors, bitmaps, soundtrackers, movies - whatever. Once
  37. a renderer is written and installed, it's available for all apps that can
  38. take it (see appropriate docs)
  39.         - You can use the Tornado multiprocessors. Although these are far
  40. more generalised than just for this one, these can convert between file
  41. formats (as mentioned above), but can also do complex tasks eg; rotate a
  42. JPEG. This may be done not only on a local processor, but perhaps on a second
  43. processor or a processor on a machine on the other end of a network see
  44. appropriate docs)
  45.  
  46. (i): Virtual memory works by breaking up very long block into much smaller
  47. ones (usually a multiple of the track size of the disc media upon which the
  48. cache is being kept for speed). Each of these blocks has a time associated
  49. with it (OS_Monotonic) ie; when it was last accessed using Tornado_Getaddr.
  50. When necessary, blocks past a certain age get dumped to disc and it is stored
  51. where they are (disc pathname). This allows a 2560x2048 32 bit sprite (taking
  52. normally 20Mb) to be edited on a 1Mb machine, as given that there would be an
  53. average 75 byte header, and with 2048 blocks of 10240 bytes each (=2 tracks
  54. on floopy E format) = about 170k of memory + 10240 to store each block.
  55.  
  56. The common tornado heap help in RMA is a special tornado heap, and is
  57. referenced by passing 0 as the heap start to the Tornado heap SWIs. It
  58. features relocatable blocks with auto-garbaging, and fixed blocks are
  59. supported too. Heaps are also relocatable, so you can have a heap in a heap.
  60. Also, heaps can be auto-extending, ie; they will increase/decrease the
  61. allocation of whatever they are stored in. In the case of postslot heaps,
  62. they will automatically call Wimp_SlotSize to alter the size of the heap.
  63. This makes setting up postslot heaps extremely easy.
  64.    Blocks in these special heaps are referenced by their handle, a negative
  65. number. This handle is passed to all heap operations, and the program need
  66. not worry where the data is really stored. When it needs to access the data,
  67. it calls Tornado_Getaddr, which returns the current address of that block.
  68. Fixed blocks are referenced a la OS_Heap style.
  69.  
  70. Another heap used by Tornado is the subtask heap, referenced by 1 - but this
  71. is for the exclusive use of subtasks - see the appropriate documentation.
  72.  
  73. Memeory management with Tornado is something you will never have to fret
  74. about again.
  75.