> Your knowlege of this is so far beyond mine I can barely follow. Even
> that is too complimentary to describe the gap, but I'd rather not
> discourage you by measuring the gap. In this I follow.
Oh, I doubt it. I just talk big. ;-)
> I was suggesting a software approach (virtual mmu), but the Atari XE has a
> fairly capable mmu in that it allows multiple processors to access memory
> separately without the intervention of the cpu. I think a combination of
> custom software and this hardware would perform better than a solely
> software approach would. I could well be wrong, but with my limited
> knowlege it is hard for me to find a fault in the argument. LUnix is a new
> word for me. Any more info? I could search for it, but you seem to know
> your stuff and that is a rare thing I'm not likely to find in a blind
> search.
No, I agree, custom hardware and software would be the best approach. The
problem with using something like this -- and granted I don't know that
much about Atari internals, so maybe there's an MMU mode or application
that could be exploited for a similar effect -- is that I'm not aware of any
drop-in device for the 6502 that gives you something like a "memory fence"
where, say, a fetch for location $0000 in the virtual addressing space of a
process really goes and grabs location $2000 in actual RAM, or causes a
page fault so that the kernel needs to go and grab "page" $0000 off disk and
get a fetch from that. This is partially the fault of the 6502's architecture
in that the only IRQs you get are the regular IRQ and the NMI, so you'd have
to make a slightly complicated IRQ handler to poll and sort out where an
interrupt is coming from (regular clock IRQ? NMI? NMI because of a page fault?
IRQ because the scheduler says another process is up? etc., etc.), but C64s
do this anyway for their array of IRQ sources (it's just expensive to do all
that polling) and at the same time I think such a device is possible. I just
don't have the technical skills to build one.
So, the software approach instead intercepts all the opcodes and does all the
address decoding logic before the processor ever gets to the opcode of a
process. The kernel reads through, corrects the locations operands are pointing
to, handles page faults if needed, and either hands the newly "safe"
instruction to the CPU, throws a fault if the instruction cannot be made
safe or is illegal, or handles it internally (like a branch moves the emulated
PC in the kernel, a PHA/PLA/PHP/PLP manipulates the internal stack image, and
so on). This also makes a rock solid OS, since no unsafe instruction ever gets
control of the entire machine before the kernel decides it's safe. Slow, yes,
but since not all the instructions are emulated it's faster than one might
expect.
Hopefully this makes some sense :-)
--
----------------------------- personal page: http://www.armory.com/~spectre/ --
Cameron Kaiser, Point Loma Nazarene University * ckaiser_at_stockholm.ptloma.edu
-- Really???? WOW!!!!! I'm shallow TOO!!!!! -----------------------------------
Received on Tue Jan 16 2001 - 17:49:45 GMT