> Why? You don't need to have a MMU for multi tasking.
> MMUs are ment for virtual addressing which is a
> complete different concept.
> They are also used for address translation and memory
> protection. Both usefull functions in a multitasking
> system and both needed to implement virtual memory
Virtual addressing always includes address translation.
And Memory protection is again not necersary part of a
MMU, and also not needed for multitasking nor virtual
addressing. It's a nice feature, but so is reentrant
coding and a hardware stack.
The basics for virtual memory in a real systems is a
way to translate a programm address (virtual ones)
into a physical (*1) memory address, a way to detect
access to a not allocated address and a way to restart
the access issueing instruction.
For translation a simple unit consisting of a RAM
whose address is taken from some bits of the CPU
(virtual) address, and the data output is connected
to the physical address lines. The number of lines
taken to address the translation RAM defines the block
size, while the nuber of data bits used as replacement
(times block size) defines the maximum physical address
space - which may larger or smaller than virtual (*1)
Now we have already virtual addressing - in this
way every address desoding is already a form of
virtual addressing, since you assign CPU addresses
to physical memory addresses.
Next step is detecting address faults. This can be
done either by a seperate on bit wide RAM with a
tag to define for every virual address block the
state (valid/not valid), or by defineing a unique
value which is used as not assigned. A usefull
combination could be all bits high, so all we need
is a NAND gate to produce a /invalid signal as soon
as the CPU accesses a not allocated page. In either
way the result is used to generate an interupt to
tell the CPU about the address violation.
Last but not least the interupt function has to
compute the faulting page, see what's necersary here
(depending on OS and allocation status either task
termination or loading the page from some swap device
int physical memory and modifying th translation table),
and if needed analyzeing the last instruction and
restarting it.
I haven't seen anything about memory protection in
here and I haven't seen anything about multitasking
either.
Gruss
H.
(*1) Often the term real memory is used, but that's
not correct. Physical memory is the memory installed
in a machine, while real address space is the addressable
amount of RAM by a CPU without using virtual addressing.
Virtual address space can never excede real address space
(After all, it's the maximum address range generated by
the (logical) CPU), while physical memory can go beyond
real or virual address space.
(*2) Most people thinks about virtual addressing as
a way to extend available memory beyond physical memory.
A scheme used by simple unix systems, and early
mainframes. More often than not, virtual addressing
is used to extend the CPU address space to handle
a larger REAL memory than the CPU could manage
otherwise. Already since the early 80s, IBM compatible
mainframes allow real memory to go way beyond the 24
(or later 31 Bit) address space of the (user visible)
CPU. For example we had did use in 1984 a CPU with 64
meg of RAM while the CPU address space was only 16 meg
(only 12 meg user address space). Before the new 64 bit
extension, actual mainframes often had a physical
memory of more than 100 GByte, but only a CPU address
space of up to 2 gig (31 Bit addressing). The 64 Bit
extension offered a way to manipulate a larger address
space on user level.
Except for very early systems, where memory was extreme
expensive, this was also the same for 8 Bit CPUs.
Physical memory did exeed the address space of the CPU.
So memory management for 8-Biters was a way to manage
more than 64K for a CPU which could only address 64K.
Things like pageing, or page faults where never an issue.
I guess everyone remembers CPM 3.0 and it's management
scheme. Virtual addressing without pageing or multi
tasking.
--
VCF Europa 4.0 am 03./04. Mai 2003 in Muenchen
http://www.vcfe.org/
Received on Tue Feb 11 2003 - 10:23:00 GMT