phil@brl-tgr.ARPA (Phil Dykstra ) (07/08/84)
Does anyone know what has happened to the MC68451 (the MMU that was supposed to work with the 68010)? I have heard rumors that the original release did not work do to a design oversight. Is this chip being made? Is there any other/better way to get memory management with a 68K processor? Does the 68010 offer anything over the plain 68000 (other than minor micro-code improvements) if it does not have a MMU? Any comments on this matter would be *greatly* appreciated. Thanks. phil@brl
jds@rlgvax.UUCP (Jack Slingwine) (07/09/84)
The M68451 predates the M68010, should still be available and
is documented in "M68000 Programmer's Reference Manual (third
edition)" (for availability, see below).
I had (briefly) experimented with the M68010 using the M68451
and everything seemed to work fine. Based on my experience with
the M68451, you should do your own MMU or wait for Motorola's
(rumored) demand paging MMU chip (the M68451 is not a demand
paging MMU, although it could support some form of virtual memory).
As far as differences between the M68000 and M68010: "M68000
(16/32-BIT MICROPROCESSOR -- Programmer's Reference Manual)
(forth edition)" is the book you want to consult, available
directly from:
Prentice-Hall, Inc
Englewood Cliffs, N.J. 07632
(201) 767-9520
For ~$20 a crack. This manual documents the M68000, M68008 and
M68010 (but NOT the M68451) (bleed tabs and revision bars indicate
the differences between the different microprocessors). Differences
between the M68000 and M68010 include:
Addition of VBR, SFC and DFC registers:
- The Vector Base Register holds the address of the
start of the interrupt vectors (i.e. you can move them
from "0").
- The Source Function Code and Destination Function Code
registers (when used with the MOVES instruction) give
you a "better" way of moving between address spaces (i.e.
kernel to user and back).
Ability to continue instructions and a "better" exception stack
layout:
- Upon a bus or address error, certain words of the processor
internal state are dumped onto the stack, allowing
continuation upon subsequent RTE.
- The stacks for all exceptions have the same four words on
the stack top, bus and address error have their additional
information below this.
Addition of new instructions:
MOVEC allows you to manipulate the VBR, SFC, DFC and USP.
MOVES allows you to move between the address spaces specified by
the SFC and DFC.
MOVE from CCR
allows you to directly examine the condition codes (this
was formerly done by "MOVE from SR" (see below)).
RTD Return and Deallocate -- new linkage primitive.
Modification of instruction:
MOVE from SR
has been made privledged. This prevents user mode programs
from determining which mode they're running in (allowing you
to test operating systems in user mode).
Definition of eight "breakpoint" illegal instructions:
0x4848-0x484f cause an illegal instruction exception to
be generated with a "breakpoint" bus cycle prior to
exception processing (FC0-2 held high, address lines low);
this could allow you to trigger a logic analyser.
Addition of "loop mode" to DBcc instruction:
A DBcc together with certain one word instructions
triggers a "loop mode" in which no program fetches are
generated. This can be used to effect a "block move"
instruction with a:
1$: move.X (aX)+,(aY)+
dbf dZ,1$
sequence.
Jack Slingwine
{seismo,ihnp4,allegra}!rlgvax!jdsfair@dual.UUCP (Erik E. Fair) (07/21/84)
The 68451 is indeed working and available. This system is using one as
I type this followup. UniSoft Systems, the System V UNIX porting house
has done 26 ports of UNIX to 68000 systems with the 68451 MMU in them.
However, I agree with jds@rlgvax.UUCP (Jack Slingwine) that it isn't the
greatest MMU in the world, and that you might be better advised to wait
either for the new Motorola MMU or use the national semiconductor MMU.
Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA
dual!fair@BERKELEY.ARPA
{ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair
Dual Systems Corporation, Berkeley, Californiamats@dual.UUCP (Mats Wichmann) (07/23/84)
As Erik pointed out, the 451 MMU exists - we have been shipping
product with this chip since May, 1982. As to whether it is a good
chip or not - not great, but it works. Who can afford to wait years
until someone `does it right' when the market windows are so small?
You have to come out with whatever is feasible at the time you
are designing the product, which is why we use a 451, Sun uses
something of their own design with TTL chips, most of the rest of
the micro-unix world uses one or the other of those schemes, and very
few people are using the National MMU.
Mats Wichmann
Dual Systems Corp.
...{ucbvax,amd,ihnp4,cbosgd,decwrl,fortune}!dual!matsgeoff@callan.UUCP (Geoff Kuenning) (07/27/84)
Jack Slingwine gave an excellent summary of the major 68010 differences in his note. However, I cannot resist sticking my nose in and pointing out a few more things: The 68010 has generally speeded-up instructions compared to the 68000; we find about a 15% improvement when running at the same clock speed. The speedups are mostly in the common instructions: moves, adds, etc. This is probably the biggest payoff of having a 68010 in a non-MMU system. The 68010 has more lenient bus-error timing. This can be a factor in an ECC memory design which reports ECC problems with bus errors, since ECC status is typically available quite late in a memory cycle. I was looking up some 68010 instruction execution times and discovered something interesting: the "loop mode" is still not the fastest way to move memory. The execution time for "movl a0@+,a1@+" in loop mode is 22 clocks (loop continued; I am assuming a large block of memory). On the other hand, if you use move multiple (as discussed previously in this newsgroup) you must execute four instructions: "moveml a0@+,#mask" where 'mask' specifies 12 registers, "moveml #mask,a1@", "addl #12*4,a1", and "dbra d0,loop". This all takes 236 clocks per pass, compared with 264 clocks for an equivalent amount of moving in loop mode. On the other hand, you have to do a divide instruction (122 cycles) to get the loop counter; this only pays off if you have more than 60 longwords to move. MMU's: The 68451 is a great MMU if you have a segmented architecture with very few (32 or less) segments. Since the PDP-11 had only 8, Unix fits quite well on such an MMU. Unfortunately, the 451 introduces at least one wait state, so you have to pay CPU performance unless you introduce a cache ahead of the MMU. When you get to going virtual on a 68010, however, the 451 simply can't hack it. Not enough distinctly identifiable pages. The 68881 Paged MMU has been formally announced, but no silicon has actually seen the light of day. I have seen some specs; it is a pretty neat and flexible little device--one of those satisfy-everybody (once you figure out how to set it up) jobbies in the USART/PIO mold. There is some doubt among my rumormongers that the chip will ever actually come to fruition--but then I heard that about the 020. -- Geoff Kuenning Callan Data Systems ...!ihnp4!wlbr!callan!geoff