bqt at update.uu.se
Sat Jul 4 18:33:39 CDT 2015
On 2015-07-04 20:58, Brian L. Stuart wrote:
>> 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.
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.
> 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.
Yes. SUN did their own MMU, which if I understand things right, were
much more sane than the 68451.
>> 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.
Thanks. I was trying to remember which, but my brain failed me.
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
More information about the cctech