Memory Management

Introduction

The RISC OS machines work with two different types of memory - logical and physical.
The logical memory is the memory as seen by the OS, and the programmer. Your application begins at &8000 and continues until &xxxxx.
The physical memory is the actual memory in the machine.

Under RISC OS, memory is broken into pages. Older machines have a page of 8/16/32K (depending on installed memory), and newer machines have a fixed 4K page. If you were to examine the pages in your application workspace, you would most likely see that the pages were seemingly random, not in order. The pages relate to physical memory, combined to provide you with xxxx bytes of logical memory. The memory controller is constantly shuffling memory around so that each task that comes into operation 'believes' it is loaded at &8000. Write a little application to count how many wimp polls occur every second, you'll begin to appreciate how much is going on in the background.

MEMC : Older systems

In ARM 2, 250, and 3 machines; the memory is controlled by the MEMC (MEMory Controller). This unit can cope with an address space of 64Mb, but in reality can only access 4Mb of physical memory. The 64Mb space is split into three sections:

  0Mb - 32Mb  :  Logical RAM
 32Mb - 48Mb  :  Physical RAM
 48Mb - 64Mb  :  System ROMs and I/O

Parts of the system ROMs and I/O are mapped over each other, so reading from it gives you code from ROM, and writing to it updates things like the VIDC (video/sound).

It is possible to fit up to 16Mb of memory to an older machine, but you will need a matched MEMC for each 4Mb. People have reported that simply fitting two MEMCs (to give 8Mb) is either hairy or unreliable, or both. In practice, the hardware to do this properly only really existed for the A540 machine, where each 4Mb was a slot-in memory card with an on-board MEMC. Other solutions for, say, the A5000 and the A410, are elaborate bodges. Look at http://www.castle.org.uk/castle/upg25.htm for an example of what is required to fit 8Mb into an A5000!

The MEMC is capable of restricting access to pages of memory in certain ways, either complete access, no access, no access in USR mode, or read-only access. Older versions of RISC OS only implemented this loosely, so you need to be in SVC mode to access hardware directly but you could quite easily trample over memory used by other applications.

MMU : Newer systems

The newer systems, with ARM6 or later processor, have an MMU built into the processor. This consists of the translation look-aside buffer (TLB), access control logic, and translation table walk logic. The MMU supports memory accesses based upon 1Mb sections or 4K pages. The MMU also provides support for up to 16 'domains', areas of memory with specific access rights.
The TLB caches 64 translated entries. If the entry is for a virtual address, the control logic determines if access is permitted. If it is, the MMU outputs the appropriate physical address otherwise is signals the processor to abort.
If the TLB misses (it doesn't contain an entry for the virtual address), the walk logic will retrieve the translation information from the (full) translation table in physical memory.
If the MMU should be disabled, the virtual address is output directly as the physical address.

It gets a lot more complicated, suffice to say that more access rights are possible and you can specify memory to be bufferable and/or cacheable (or not), and the page size is fixed to 4K. A normal RiscPC offers two banks of RAM, and is capable of addressing up to 256Mb of RAM in fairly standard PC-style SIMMs, plus up to 2Mb of VRAM double-ported with the VIDC, plus hardware/ROM addressing.

On the RiscPC, the maximum address space of an application is 28Mb. This is not a restriction of the MMU but a restriction in the 26-bit processor mode used by RISC OS. A 32-bit processor mode could, in theory, allocate the entire 256K to a single task.
All current versions of RISC OS are 26-bit.

System limitations

Consider a RiscPC with an ARM610 processor.
The cache is 4K.
The bus speed is 16MHz (note, only slightly faster than the A5000!), and the hardware does not support burst-mode for memory accesses.
Upon a context switch (ie, making an application 'active') you need to remap it's memory to begin at &8000 and flush the cache.
I'll leave you to do the maths. :-)

Return to assembler index