Re: mmu for 65c02

From: A. Fachat (afachat_at_gmx.de)
Date: 2005-04-20 16:28:26

Gábor Lénárt wrote:

>On Wed, Apr 20, 2005 at 02:00:04PM +0200, A. Fachat wrote:
>  
>
>Oooopsss! What about domain name 6502.org? It does not work at this moment,
>it seems ...
>  
>
Maybe try it later.

>Yep :) And anyhow I would like to implement such  a system in software. This
>is very useful, because you can create quite complex "mmu", like paging and
>even page protection (on page fault you can generate a signal for example)
>and such. If you implement a system like this in software with eg a lib6502
>  
>
I used VICE to implement an emulator for my selfbuilt CS/A65 system :-) 
The emulated system should be
on  6502.org too when it is back. (although based on a very old version 
of VICE).

If you do page faults, you have to notice that you would never be able 
to put that into hardware, as the
6502 lacks appropriate features to handle page faults (like being able 
to restore the registers to the
values before the faulted opcode executed)

>if I'm right. Now, inmagine, that the WHOLE mapping table is eg 1Kbyte long,
>and you can specify the offset in that "big" table for usage. Eg, for
>hardware pid (process id) zero, entries between 0 and 15, for pid 1 entries
>between 16 and 31 etc will do the mapping. So switching between processes is
>only altering the "start" address of that table, not storing 16 bytes on
>each context switching (which is not too expensive, but for 256 bytes length
>pages it would be for my ideas).
>  
>
If you ever want to put that in hardware again, I would advise to use 
different address lines for
the position in the mapping and the task number (i.e. make each mapping 
a fixed size of a power
of 2 so you can address the page in it with, say, 8 address bits, and 
use the upper address bits of
the mapping table as process selector. In the case of an 1k mapping 
table this would give only i
4 possible processes (1k = 4*256 byte mapping), but the hardware effort 
would be smaller by
magnitudes: If you only give a start address in the mapping table per 
process, the CPU address
has to be added to this start address, then this will be used as address 
in the mapping table and
the mapping value will have to be looked up, and all with appropriate 
timing.... not so easy I'd say.)

>OK, but your design has 4Kbyte page size so you can't page only the
>stack with this MMU ...
>  
>
No, I cannot. Each process - possibly containing multiple threads! - in 
this system has a single mapping.
I.e. the zeropage and stack is shared within a process, but not between 
processes. Here each process
has its own mapping.

[In OS/A65 each process has its own memory mapping. A process can have a 
number of threads,
that all live in the same memory mapping of the process they belong to. 
So a "full size" process contains
threads as "lightweight processes" without own memory mapping. In fact 
each process has at least
one thread, namely the one that executes the process.]

>>processes (without MMU) using a memory management software. When code is 
>>loaded
>>into memory, it is relocated by the loader to use unused parts of the 
>>zeropage (which is
>>requested from teh memory management software).
>>    
>>
>Yes, but in this way the total number of processes is limited by the
>size of zero page (256 byte) which CAN BE avoided by useing private zero
>pages for each processes at least in theory ...
>  
>
Not the number of processes (with MMU, each process has its own 
zeropage/stack mapping), but the number
of threads is limited. (Of course without MMU process = thread, so there 
is this limit for processes too)

The advantage of your scheme is that you could have a common mapping of 
the zeropage for all
threads in a processes, but each thread could have its own stack 
mapping. This is not possible in
my system with 4k page size, but only in yours with 256 byte page size.

André




       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.