![[Select]](../../imgs/seldoc.png)
|
Dynamic Areas |
 |
Dynamic area changesFrom Kernel 9.06 onward there are a number of new dynamic areas which are provided by the operating system. These areas provide a legitimate mechanism for locating previously fixed regions of memory. The full list of dynamic areas is as follows : -1 Application space Each of these areas is described below. Where not expressly stated below, the address and size of the regions is variable with OS versions. System heapThe system heap is a private area used by the Operating System for allocation of structures vital to the system's operation. This includes, but it not restricted to :
Under earlier versions of the Kernel, the system heap was writable in USR mode. This has been changed in order to improve system stability by making the region read-only in USR mode. Under earlier versions of the Kernel, the system heap was used for system variable management and as FileSwitch workspace. This has been changed to remove such collusion. System variables (and the entire system variable system) is now managed by the SystemVars module. FileSwitch now uses a private dynamic area for its memory allocation. These changes have meant that the system heap no longer needs to be as large as it has been under earlier versions of the OS. It has been reduced in size from just under 3M to just under 2M. The system heap does not contain any executable components and may be outside of 26 bit space on 26 bit systems in future. Relocatable Module AreaThe RMA is unchanged in operation. On 26 bit systems it will remain within 26 bit space. On 32bit systems it will remain within 31 bit space (that is, it will not have an address which is negative if used in a signed context). Screen AreaThe Screen area is no longer provided by the Kernel. The LegacyScreen module provides a fake implementation of the screen area to ensure that clients which read the dynamic area do not fail. The contents of the area are not, however, the screen. Access to the screen should only be performed through the defined values returned by OS_ReadVduVariables. System Sprite areaThe system sprite area has, since Select, been managed by the SpriteUtils module. Its contents should be considered private to SpriteUtils. Font cacheThe font cache area has, since Select 2, been managed by the FontManager module. Its contents should be considered private to FontManager. RAM filing systemThe RAM filing system has, since Select 3, been managed by the RAMFS module. Its contents should be considered private to RAMFS. Free poolThe free pool is unchanged in behaviour. This may change in the future. VRAM RescueThe VRAM rescue area was used under RISC OS 4 (and Select 1-3) to provide a mechanism for returning slower VRAM pages to the free pool, replacing them with DRAM. Since VRAM is now managed solely by the video driver modules, it is no longer available for use as normal memory. The VRAM rescue area has been removed. Kernel buffersThe kernel buffers area provides a similar function to that of the system heap, but for more specialised tasks. It is private to the Kernel. Abort SVC and IRQ stack copyThe Abort SVC and IRQ stack copy area is used by the Kernel to take a copy of the SVC and IRQ stacks when an abort occurs. This information is available to Privileged Backtrace Structure (PBTS) tools, such as BTSDump. During the processing of an abort within a privileged mode the dynamic area contains a copy of the entire SVC stack, followed by the entire IRQ stack. The registers and other parameters at the time of the abort can be obtained from the PBTS chain. The area is read only in USR mode, and should only be read by diagnostic tools. This area is not resizable. Operating system ROMThe Operating System ROM area provides an explicit description of the location of the ROM and its extent. Diagnostic tools and other specific applications may use this information to provide a logical memory map without reliance on fixed constants. The contents are read only in all modes. This area is not resizable. SWI dispatch and IRQ workspaceThe SWI dispatch tables have been moved within the memory map due to an increase in the size of the IRQ stack. The tables are private to the Kernel and should not be manipulated by external applications except in unavoidable circumstances. Consult the OS_ReadSysInfo6 document for the defined mechanism for reading the table address. Such use is strongly discouraged. This is the region which has previously been described as 'Cursor/System/Sound' within the Task Manager display. This area is not resizable. SVC stackThe SVC stack area provides an explicit description of the location of the SVC stack and its extent. This is the preferred mechanism for locating the SVC stack. The stack will remain based at a 1M boundary, but its size may increase in future versions of the operating system. Execution of code from the SVC stack is strongly discouraged. Although the stack currently remains within 26bit space on 26bit systems it may be moved to higher memory in future. This area is not resizable. IRQ stackThe IRQ stack area provides an explicit description of the location of the IRQ stack and its extent. This is the preferred mechanism for locating the IRQ stack. The stack will remain based at a 1M boundary, but its size may increase in future versions of the operating system. It is strongly discouraged that the IRQ stack be used for executing code. Although the stack currently remains within 26bit space on 26bit systems, it may be moved to higher memory in future. This area is not resizable. UND stackThe UND stack provides an explicit description of the location of the IRQ stack and its extent. This is the preferred mechanism for locating the IRQ stack. The stack will remain based at a 1M boundary, but its size may increase in future versions of the operating system. From RISC OS 4 onward it has not been possible to execute code in the UND stack. This area is not resizable. Level 2 Page TablesThe level 2 page table area provides an explicit description of the location of the page tables. The address of the level 1 page tables can be inferred from the address of the ROM within the level 2 page tables. Because the ROM is mapped using Level 1 page table entries of 1M each, the space which would have been occupied by its Level 2 page table entries is 'spare'. This is where the Level 1 Page Table entries are mapped. Its size will appear to be 0 because it is sparsely managed by the Kernel. Future versions of the Kernel may explicitly state the size used by the page tables. This area is not resizable. Operating system page tablesThe operating system page tables area, or 'CAM map', provides a table of the mapping between page number and logical address. This area is not expected to be manipulated outside of the Kernel. Should such manipulation be necessary, other necessary details about the table can be read from OS_ReadSysInfo6. This area is not resizable. Miscellaneous notesThere is no defined ABT mode stack. All abort operations will be executed within the SVC stack, having first preserved the state of SVC mode. |
 |
This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation. HTML document version 1.03 3rd November 2015 |