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.