From: A. Fachat (afachat_at_gmx.de)
Date: 2005-04-20 14:00:04
Hi Gabor, interesting idea - not that I haven't done that before.... :-) First of all, you may want to have a look at http://www.6502.org/users/andre and there under CS/A65, GeckOS and OS/A65, which describe hardware an software that implement a similar system. Of course it's more fun to do things like that yourself :-) Gabor Lenart wrote: >space, I mean every page (256 bytes of memory starting at a 256 byte aligned >address) can be assigned to let's say any of 65536 possible 256 byte sized > > IMHO using 16 bit values for remapping is a substantial overhead as compared to 8 bit values (in terms of context switch time, process table size - remember, with your mapping, a process table contains 512 byte of memory mapping (256 pages Ã 16 bit mapping info each) CS/A65 uses 16 pages Ã¡ 4 kByte, that can be mapped out of 256 pages making a total of 1 MByte of memory. But the CPU has to reload the mapping tables each time on a context switch. >page (that's 16Mbyte). Also, there would some hardware support for task >switching (so we're talking about multitasking system), there would be > > You mean, the mapping table would be set in hardware instead of having the CPU reload the mapping each time? Interresting idea! >several mappings, one for each task (can be process or a thread). "task >switching" would be only a selection of a mapping to use (well, for real >it's more complex, you should also save registers etc). As you can see, >you can even share memory between two (or more) tasks by mapping the same >physical (from the 16Mbyte memory space) page into two (or more) address >space mapping for 65c02. The whole story is a software based 65c02 simulation >of course. Other stuffs like syscalls, 'kernel' vs 'user' space is not >mentioned here, btw. > > The 6502 has not distinction between "User" and "Kernel" space. You would have to invent a thing like this yourself. E.g. by hardware-monitoring the address lines >The problem is about threads. If we're talking separated processes, each >can have its own memory space. Threads can be implemented easily as normal >processes but with the same memory context. Of course the stack cannot be >shared, so page #1 (stack) should be private for each processes. > > In GeckOS I have several methods of "stack sharing": 1) Systems without MMU can share the actual page1, by using different parts of the page. Of course stack size per process/thread is limited then. 2) Systems without MMU can copy-share page, where on a context switch from one thread/process to another the stack is copied to a thread-specific safe-area 3) On Systems with MMU, the page 1 is simply replaced by a new memory mapping when processes are switched. (Don't remember though what happens when threads are switched) >This whole long story is about only one thing: what's about zero page? > > In GeckOS I share the zeropage between threads (with MMU) and between threads and 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). AndrÃ© Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.