WindowManager Memory Management (changes)

» WindowManagerPart 7 - The Desktop?

» The Technical Window Details Manager

» Memory managementTechnical Details

Overview

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 allows the user limited control of some memory allocations. This is achieved via Task Display which is accessible by clicking on the Task Manager icon on the icon bar.

Task Display

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. For example, reducing the memory allocated to the RAM disc could mean more memory for allocation to system sprites. This allows the user to decide how to make best use of the system’s memory.

Two bars, named ‘Free’ and ‘Next’ can be altered by the user. 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. This is only used if the application does not explicitly specify how much memory is required by using the *WimpSlot command.

Memory Mapping

RISC OS uses co-operative, not the more widespread pre-emptive method of multi-tasking. When an application is given control via a return from Wimp_Poll, the Wimp must map the correct pages of physical memory to the application’s workspace, which starts at logical memory address &8000 (32,768).

Note: The smallest unit of mapped memory is called a ‘Page’ and is usually either 8K or 32K in size.

This memory mapping is carried out independently by the Wimp without any action on the part of the application.

Memory Allocation

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.

If they require more memory, applications can use the Wimp’s free pool of memory. Only applications executing in SVC (supervisor) mode can make use of this memory; 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 should not 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 dynamically to adjust an application’s memory allocation by dragging the 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 issues Message_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.

Memory Tips

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.

See also

• Wimp_Poll
• Wimp_SlotSize
• Wimp_ClaimFreeMemory
• Message_SetSlot
• *WimpSlot