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.