4 Jul
2015
4 Jul
'15
4:33 p.m.
On 2015-07-04 20:58, Brian L. Stuart wrote:
Ok. I didn't know it was some version of 7th ed. I didn't even know that
managed to get much beyond the PDP-11.
Anyway, it's sad, because the PDP-11 hardware can easily handle demand
paged memory. It's just that no one really found it worth the effort to
implement it when you only have 8 pages, and have way more physical
memory than the virtual memory space can address.
Yes. SUN did their own MMU, which if I understand things right, were
much more sane than the 68451.
Thanks. I was trying to remember which, but my brain failed me.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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.
Yes. Essentially traps which can happen in the middle of instructions.
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.