From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2005-04-20 15:12:35
Hi André,
On Wed, Apr 20, 2005 at 02:00:04PM +0200, A. Fachat wrote:
> 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.
Wow! :-) OK, I'm about checking it :)
Oooopsss! What about domain name 6502.org? It does not work at this moment,
it seems ...
> Of course it's more fun to do things like that yourself :-)
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
compliant API even executed in host OS space (I mean you have got the
emulator runnign eg under Linux or BSD, which emulated a 65c02 with such an
mmu we're talking about, but the lib6502 implementation itself is written in
C and runs on the host system with 'escaping' from emulation when lib6502
call made), you can test softwares without the risk to crash program with
the whole system (since eg a C64 hasn't got any hardware level memory
protection). It can be very useful for cross-platform development.
> >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)
Yes, but because I was about implement an EMULATED system running on
a powerfull PC for example, it does not matter at all :) Of course, if
someone want to create a real hardware like this, it's another story.
> 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!
Yes. EG for CS/A65 there is 16 pages for mapping in the 64K CPU address
space from total of 1Mbyte space. This requires 16 byte long mapping table
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).
> >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
Sure, this is not about this topic, I only wanted to write here, that
I oversimplified jobs of the OS, I mean if I have a hardware memory context
for each process, and one for the kernel itself, than you have to do
more complex page table altering tasks, since kernel want to map some 'user'
space as well, eg on transfer data from/to address space of a process.
> 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.
Yes.
> 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
Sure.
> 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)
OK, but your design has 4Kbyte page size so you can't page only the
stack with this MMU ...
> 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).
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 ...
So my problem that using a common zero page will cause the same limit
as with hardware without an MMU ... One of the major advantage of this MMU
would be the per process stack and zero page (both of them are only 256 bytes
long), and you loose one of the advantage of this mmu scheme if you use
shared common zero page for all processes ...
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.