Showing changes from revision #2 to #3:
Added | Removed | Changed
The Wimp is responsible for managing memory across all system areas. e.g. screen memory, application workspace, system sprites, font cache etc…
Although the system has direct control over all aspects of memory, RISC OS implements allows an innovative method of allowing the user limited control of some memory if allocations. they require. This is achieved viaTask Display which is accessible by clicking on the Task Manager icon on the icon bar.
Task Display is an application provided by the Operating System that gives a graphical representation of the system memory resources using bars to display the amount of memory set aside for each part of the system.
The user can re-size the length of a bar to adjust the allocated memory. Reductions in memory of one part of the system can mean an increase in another should the user require it. e.g. For Reducing example, reducing the memory allocated to theRAM disc could mean more memory could for be allocation allocated to system sprites. This allows for the user to decide how to make best use of the systems system’s memory memory. at any given time.
Two important bars, bars named that ‘Free’ and ‘Next’ can be altered by the user user. are They named ‘Free’ and ‘Next’. Respectively, they provide the size of free available memory available, and the maximum amount of memory that can be used by the next application to be loaded, loaded. although This this is only used if the application does not explicitly specify how much memory is required by using the*WimpSlot command.
Although RISC OS is a multi-tasking Operating System, it uses co-operative, not the co-operative method rather than the more popular widespread pre-emptive multi-tasking method method. Because of this, multi-tasking. applications When running within the Wimp wrongly assume that they have total control over the system and its memory, and that no other application can be running. As a result, when an application gains is given control via a return fromWimp_Poll , the Wimp must map the correct pages of physical memory to the applications application’s workspace workspace, starting which starts at location &8000 (32,768). This is called its logical memory as address opposed &8000 to (32,768). the system physical memory.
Note: The smallest unit of mapped memory mapping that can be achieved is called a ‘Page’ and is usually either 8K or 32K in size.
This memory mapping is carried out invisibly independently by the Wimp and without as any a action result on applications the are part unaware of that the it application. happens.
Applications can (and usually should) specify the amount of memory they need to run without problem. This is achieved by Wimp_SlotSize. This has the same effect as manually adjusting the size of the ‘Next’ bar within Task Display.
Applications If should they require more memory memory, for applications a temporary buffer can request exclusive use of the Wimps’ Wimp’s free pool of memory. Only applications executing inSVC (supervisor) mode can make use of this memory, memory; as it is protected against user-mode access. In addition, while the memory is claimed for use, the Wimp cannot dynamically alter the memory size of other parts of the system. So to reduce any potential problems, applications that request the memory shouldnot claim it for extended periods of time. i.e. across multiple Wimp_Polls.
To claim use of this memory, an application should call Wimp_ClaimFreeMemory.
It is also possible for a user to dynamically to adjust an application’s memory allocation by dragging the applications application’s bar within Task Display. However, this is only possible if the application agrees to this when it is first loaded. When an application is loaded, the Wimp issuesMessage_SetSlot and if the application will allow its memory to be dynamically allocated by the user, should respond. The Wimp will also issue the same message if a user tries to alter the application bar that has already specified it will allow the memory allocated to be changed.
Applications with complex or heavy memory requirements should use Wimp_SlotSize at run time. This allows applications to both take and give back memory to the Wimp.
BASIC programs may use the END=&xxxx
to call Wimp_SlotSize instead.
Applications written in a high level language such as C/C++ should call Wimp_SlotSize directly or use an appropriate call to specify memory requirements.
Applications should never re-configure a machine or kill modules to claim enough memory to load. Such actions are strongly discouraged.