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.