Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The 68010 and MMU's

22 views
Skip to first unread message

jo...@apple.uucp

unread,
Jul 20, 1984, 4:56:22 AM7/20/84
to
>> The one thing you do need to do is always use a 68010 in ANY scheme
>> that does dynamic memory management, (to wit, most UNIX implementations), as
>> the 68000 has unrecoverable faults when a bus-error occurrs.
>
>Also not true - Masscomp uses two 68000s. The main 68K halts on a page fault,
>and the other 68K services the page fault and restarts the main 68K. Doing it
>with one 68000 isn't possible (to my knowledge - maybe somebody out there
>*has* squeezed blood from a stone).

The apple Lisa uses a plain 68000 and *does* squeeze blood out of the stone.
Memory is segmented and code is demand loaded. The trick is that *some*
instructions are restartable. There is much magic and kludges involved.

____________________________Computare necesse est!____________________________

Johan Strandberg
Apple Computer Education Research Group [ERG]
{mtxinu,dual,nsc,voder}!apple!johan

Pat Clancy

unread,
Jul 21, 1984, 3:20:06 PM7/21/84
to
The Lisa does do demand loading of text segments, but not
data. This is possible because all the 68K instructions which could
fault on an instruction fetch are restartable (eg.: branch).
Data segments must be pre-loaded. I would be interested in any
information anyone might have indicating how useful text-only
virtual memory is.

Pat Clancy
{ucbvax,decvax,ihnp4,allegra,uw-beaver,hplabs}!tektronix!tekecs!patcl

Guido van Rossum

unread,
Jul 25, 1984, 8:19:27 AM7/25/84
to
>The apple Lisa uses a plain 68000 and *does* squeeze blood out of the stone.
>Memory is segmented and code is demand loaded. The trick is that *some*
>instructions are restartable. There is much magic and kludges involved.

A very early UNIX implementation on a 68000 by ACE in the Netherlands
did the same. Essentially, the compiler generated such a restartable
instruction at the beginning of each C procedure which tried to reach to
maximum needed stack address. The memory fault this could cause was handled
by the kernel, and the program restarted.
I guess the Bourne shell caused them the most problems.

--
Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
guido @ mcvax

Guy Harris

unread,
Jul 26, 1984, 2:09:00 AM7/26/84
to
> The 68451 certainly does exist and is available, (although not in
> massive quantities). The only format i have seen it in is the square
> LCC package though.

We make (to, in my opinion, our sorrow) a 68K-based UNIX box which uses the
68451, in a DIP the same size as the 68000 chip itself.

> By the way, the types of memory management provided by the 68010
> and the 68451 are DIFFERENT, the 68010 is for VIRTUAL memory
> implementations, (and by itself is used in the Sun processor, with
> custom memory management hardware), and the 68451 performs MEMORY
> RELOCATION only.

Not true - you can combine a 68010 and a 68451 and make virtual memory. It
could be "demand segment loading" (which is virtual memory - ask any
Burroughs mainframe programmer), or you can even do demand paging (by using
the 68451 as a sort of translation lookaside buffer, with fixed-size small
(~2KB, say) "segments".

> The one thing you do need to do is always use a 68010 in ANY scheme
> that does dynamic memory management, (to wit, most UNIX implementations), as
> the 68000 has unrecoverable faults when a bus-error occurrs.

Also not true - Masscomp uses two 68000s. The main 68K halts on a page fault,
and the other 68K services the page fault and restarts the main 68K. Doing it
with one 68000 isn't possible (to my knowledge - maybe somebody out there
*has* squeezed blood from a stone).

Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy

0 new messages