From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-04-20 20:17:47
Re,
On Wed, Apr 20, 2005 at 04:28:26PM +0200, A. Fachat wrote:
> 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)
Yes :) That's why I've written it's mainly for cross developmenting and
testing, where you can hunt bugs with eg not allow to write to a page
which holds a part of code segment of a running process for example ;-)
I mean for software implementation where it's possible to modify the
6502 itself as well. Of course for real, you can do this too, just
get an FPGA, and learn verilog, vhdl or whatever :)
> 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
Sure. This was my idea. Maybe I can't explain properly ;-)
> 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
Sure, I don't want to add! I want to complement it. I mean the "offset" in
page table to use for mapping the 64K address space of CPU is not an offset
for real, but _IS_ always start at eg every 256th entry (if we're talking
about a scheme with 256 pages per 64K). So in this scheme, the high 8 bits
of the address generated by the CPU itself selects the low 8bit address in
page table memory, and the page table selection register's content selects
eg the hight 8 bits of address in page table memory. Then the read value
(from page table memory) is the physical address to route shifted left by 8
bits. The lower 8 bits of physical address is simply equal to the 8 lower
bits of the original address generated by the CPU.
> >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.]
Yes. But in this way you can't have private stack for threads within a
process, right? I mean threads within a process should use eg different
part of the stack for example. This reduces the maximal usable stack size
within the thread. And if you want to create 16 threads there is only
16 byte stack space for one thread ;-) I would like to use 256 byte stack
even for a thread. This requires not to share the stack, at least.
> >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)
Errrrrrrrrrr ... you're right, thanks ;-) But my problem is: if I have
a process and creating a thread, than maybe I will use the same zero page
locations (eg it's a cc65 compiled software using zero pages) so they
will disturb each other, doesn't it?
Because without MMU, you can execute the same program in more times
with using another zero page positions (and other positions for code and
other data as well, of course) with relocation. But when I create a thread
within an already running process we may have trouble ... if we have
shared zero page between threads of a given process.
> 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.
You can do it as well, if you have another mapper just for stack (addresses
between $100 and $1ff). So in your project you have 4K length pages but with
a private mapper just for the stack. For threads within a process you should
share the first 4K sized page of your system, but NEVER for different
processes. Also, the separated pager 'just for the stack' should specify
different mapped location for each threads and processes of course, since
even a threads have got own stacks. This is useful if you want to keep your
design but want to exploit the possibility to use the whole zero page per
processes (and its thread(s), threads within a process shares them of
course). The only headache is having 16 element sized page table for mapping
64K in 4K steps and an additional paging setting fot the stack which is only
256 bytes long ;-)
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.