out-of-mainstream minis

[Johnny Billquist]

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

-- 
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