Brian L. Stuart
blstuart at bellsouth.net
Sat Jul 4 13:58:33 CDT 2015
> The problems revolve around the fact that instructions cannot be
> properly restarted on the 68000. Not enough context is saved. This in
> turn means you cannot do demand paging, a that will cause a memory
> exception trap, from which you cannot recover.
True, but IIRC the OP was talking about a system that ran 7th Edition
UNIX, and 7th Edition didn't do demand paging. As long as you treat
it more like a big PDP-11 rather than a small VAX, you can write a
perfectly usable OS for a straight 68000.
Remember that it's only a problem on bus error and address error
interrupts. External interrupts, like a clock interrupt used for time
sharing, don't get handled until after the current instruction is
complete. Therefore, there's no need for instruction restarting.
It was the extension of the exception stack frame in the 68010
for the group 0 exceptions that made it practical to support demand
loading for the full instruction set. The stack frames for group 1
and 2 exceptions didn't change substantially.
> Also, there is no MMU from Motorola for the 68000, so you would
> have to design your own.
There was the 68451, but you rarely saw those in the wild. Not
having ever had to make the design decision of whether to use
one, I can't really say whether the lack of design-in was primarily
a function of cost or of speed.
As far as designing your own goes, that's quite easy to do as long
as you're not trying to do a large number of small pages with the
capacity to recover from a page fault. Simple relocation and
protection with a modest number of pages can be done with just
a handful of latches and multiplexers. I recently did a small MMU
for a 6809 that mapped 128K of physical memory into the lower
48K of the address space in the form of mapping 8-16K pages
into 3-16K page frames. It just took 9 otherwise unused pins on
a parallel port and a pair of 74153s. Things don't start getting
particularly complicated until you start talking about putting page
tables in main memory and requiring a TLB.
> In addition, there is also a potential privilege escalation problem with
> the 68K if I remember right. You always have full access to the
> whole processor status word in that CPU. I can't remember what
> the scope of that issue is. It might only be information leak, or it
> might be that you can elevate yourself as well.
It's only a leak. The move to sr and other sr modifying instructions
were privileged on all members of the family. However, the move
from sr was not privileged in the 68000, but was on the 68010. Plus
what got leaked didn't amount to much. The system byte of the
status register only had the interrupt mask, the supervisor state bit
and the trace mode bit.
More information about the cctalk