[net.micro.68k] UNIX onthe 68000

kiessig@sri-unix (07/21/82)

	I'd like to stimulate some discussion on this list about
people's experiences with UNIX on the 68000.  Good or bad.  Performance,
reliability, viability in the commercial environment, etc.  

	Measurements on Fortune's 32:16 (runs at about 5.6MHz) seem
to put it about in a league with a PDP 11/34, performance-wise.  This
is with a DMA 5.25" Winchester as the root/swap media.  If there are
some benchmarks available generally, it would be interesting to
run them on a variety of 68K-based machines.

Rick

mark (07/29/82)

I have a question.  I saw several claims in this newsgroup this morning
that the 68000 does not allow reasonable paging, and that people should
wait for th 68010.  I have also seen claims by SMI and CadLinc that their
SUN board behaves exactly like the 68010 memory-management-wise, so
software will be plug compatible when the 68010 boards come out.
Will someone please explain?

	Mark

grunwald (07/31/82)

#R:fortune:-16000:uiucdcs:23900002:000:356
uiucdcs!grunwald    Jul 30 21:17:00 1982

What they mean is that their memory management will be able to handle the 68010
not that their boards will currently allow demand paging. As it stands, they
point out that they can not handle this, and that you need to wait for the
68010 for full paging. The system can handle paging of either just data or
instructions (I don't remember which) currently.

tjt (08/02/82)

68000 systems that use a second processor to handle page faults while the
first processor is in a very long memory wait can (or should) be able to
handle arbitrary page faults (i.e. there should be no reason why only
data or only program references would work).  The catch is that with the
dual processor scheme, there is nothing else you can do during a page
fault (except field interrupts -- provided the hardware allows the second
processor to handle interrupts when the first processor is stalled).
In particular, the first processor cannot run code for another process
since the paging stunt depends on that processor hanging in a memory cycle.

Depending on how independent the second processor is, you may be able to
get other useful work out of it when it isn't handling a page fault (I believe
that Apollo uses a second processor to handle the network and some graphics),
but in order to do this effectively it would need some memory of its own
(or else some very fast system memory).  The problem is that a 68000 is
basically a memory-limited machine (most internal clock cycles are used
for memory cycles), and are often faster than system memory (i.e. wait states
are required), so there isn't any extra bandwidth for a second processor
to run without drastically interfering with the first.

The limitation on page fault handling imposed by the second processor should
not be too big a problem on a single user system, although ambititous
UNIX users can easily generate several active processes (i.e. edit in
foreground with a compilation in the background), but would obviously have
a chilling effect on time sharing.