From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2005-04-21 13:36:54
On Thu, Apr 21, 2005 at 12:47:30PM +0200, Baltissen, GJPAA (Ruud) wrote:
> > The problem is about threads.
>
> Being more a hardware guy: what is a thread?
From the view point of hardware? Nothing :) At least even process does not
mean anything for the hardware :) On a CPU like i386 it's another story
because it supports building a multitasking OS by hardware (like memory
protection, task switching etc), but it's not true for 6502.
In general, threads belongs to the same 'thread group' is simply
a running instance of the same execution context, which can be inmagined
like processes, but with SHARED memory context. Of course the stack itself
is not shared because stack is used to transfer data from/to functions
to create unified callong convections for common programming languages allows
even recursion and such.
(err, sorry again for my bad English)
> > So I have to use private zero and stack page for each threads?
>
> IMHO each _program_ should have its own stack and zero page, that's for
> sure. Not knowing what threads exactly are, I only can say this: give each
> thread its own stack and ZP as well. If on the end it turns out you don't
> need them, you always can discard this feature.
>
> But then there is something else you may not forget: the registers of the
> CPU and the hardware, and the videomemory. Assume this MMU thing runs on a
> C64. This MMU enables you to do some multi-tasking. And I can imagine that
> one program needs the BASICROM and another one the RAM under this ROM. So
> you see that it is not only a matter of switching RAM but, in this case, the
> I/O-port of the 6510 has to be adjusted for each program as well. And this
> simply means that the configuration of at least this port has to be stored
> in memory somewhere for every parallel program.
I was writing about a theoretical system not a C64 ;-) That's why the
subject was choosen as 'mmu for 65c02' (why 65c02 and not 6502 for example?
because it's easier to emulate in software, eg no need for emulate illegal
opcodes), and not 'mmu for commodore 64'. So it's not a C64 and not even a
REAL system. Well, at this point at least :)
Also, I would not give access for video memory. I prefer UNIX way: abstract
almost everyting as file operations, I mean using stdout instead of direct
hw access. OK, it's not for screen oriented softwares, but this is another
story, in this thread I was about UNIX-like systems.
>
>
> > Of course, if someone want to create a real hardware like
> > this, it's another story.
>
> Being a hardware guy, I prefer real HW of course. There exist very nice MMU
> IC's, the 74HCT610 (used by Andre) and the 612, but both have a
> disadvantage: where can they be bought? My only source of 612's so far was
> scrapping older PC 286 motherboards.
> That's why I designed my own one. The core of this MMU can be found in the
> top of http://home.hccnet.nl/g.baltissen/pccard2.gif under the columns 5,6
> and 7. Using real memory, even fast cache-RAM, has a disadvantage: the
> clockspeed of the CPU is limited. (But 4 MHz should be doable IMHO).
>
> BTW, anyone knows other MMU IC's?
<offtopic>
My favorite system is Enterprise-128 ("EP128" or "EP" for short). Maybe I've
written something on this machine in this list ;) It's a Z80 based computer
(with quite good graphics, 256 colors, even different video mode for each
scanline without video interrupt, tricky timing by CPU or whatever). The
address bus of EP is 22 bit wide. The CPU address space of course is only 16
bit, the highest two bits selects one from the four MMU register (located in
chip Dave, also generates sound, and has got some interrupt controller
functionality). Content of the selected MMU register emits the highest 8 bit
for the EP bus address lines, the lower 22-8=14 is simply the lower 14 bits
of the CPU generated address. With this quite simple design, EP can address
4Mbyte memory space easily without overhacking the whole machine :) I wish
other computers would have been released with some kind of paging like this:
simply but surly enough for ANY need even in the future well at least for a
8 bit system of course :) There's eg 1MByte memory expansion for EP ;-)
</offtopic>
> Hmmm, very interesting indeed! As you can see, not all the addresslines of
> the RAMs in my MMU are used; they are conected to GND. Adding an I/O-port
> (74ALS573, 6522, 6526) to these lines means we can store 32 configurations
> (512 when using 32K*8 SRAMs) that can be choosen by one single STA $xxxx
> command.
>
>
> > ....E.g. by hardware-monitoring the address lines
>
> Doesn't work IMHO. You can generate a NMI the moment an user accesses a
> forbidden area. But the NMI will only be serviced _after_ the harm is done.
The harm itself is not a real thing if you don't allow to happen :)
I mean if a memory area is write protected, writing to there would
cause a NMI as fault, and also the MMU does not route the Write Enable
signal to the memory, so from the view point of memory the write is not
done. From the view point of CPU it is, and also after the operation the
NMI will be taken. Even the read can be denied by simply eg read always
zero if page is not readable by a process. Execute/read rights separation
woule be quite problematic anyway, because at least afaik you can't tell
that CPU reads something because it's an opcode, or because it's the
result of eg an LDA $FF operation.
> With the 65816 this is another story; here we have the ABORT input that
> breaks off the momentary instruction.
But this NMI generation scheme is enough to stop the execution
of the "bad guy" process at least. OS then kill the process. Handling
the problem like installing signal handler for segmenation fault is not
a possible solution because hardware can't give information about the
fault itself (where? why?) just the fact that there was SOME fault.
This is because you may have multiple fault within executing one
instruction (like: reading opcode, doing memory read/write).
Well, I'm not a hw guy, or at least beginner so correct me if you don't
agree :)
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.