🚀 go-pugleaf

In article <393@oz.UUCP>, frankr@oz.UUCP (Franklin Reynolds) writes:
> It is my understanding that the MMB has trouble with the TAS instruction
> if the address of the operand is not in its translation cache. In the system
> I use, a bus error is generated. I was wondering if the problem is fixed in 
> the PMMU or the M68030. 

Actually, the problem was in the 68020.  The original 68020 design would
not release the bus to another master while in the middle of a read-modify-
write operation.  It just ignored bus requests (BR*) until after the
whole operation.

One problem with this is that you can't build external hardware that
KNOWS it can always get the bus if it needs it.  Sun had this problem
in the Sun-3 design -- if a long VMEbus cycle was in progress and we
needed to do an onboard DMA cycle or something, we'd ask for a rerun of
the CPU cycle in progress, do the DMA cycle, and let the CPU resume the
VMEbus cycle.  But if it was a cycle of a r/m/w operation, the CPU would not
give us the bus.  The Motorola PMMU and MMB chips had the same problem
since they occasionally ask the CPU to rerun the current cycle, but
steal the bus before it gets the chance, to read in the right page
table entry, so that the retry will find the page table entry cached
and everything will work.

Later revs of the 68020 leave the decision to external hardware.  Since
you already know whether a r/m/w operation is in progress (the RMC*
pin), you can just avoid issuing BR* (bus request) when RMC* is active,
if you don't want to interrupt r/m/w operations.  If you don't much
care, or you want your MMU to be able to get page table entries, the
newer 68020s will let you grab the bus with BR* even during r/m/w operations.

If you have a system that bus-errors your TAS instructions due to
MMU cache misses, the recommended software workaround is to notice
in the bus error handler that the cycle was the read part of a read-modify-
write operation, make sure to load the page table entry into the MMU,
and just RTE from the bus error handler so it will rerun the cycle (like
a page fault is rerun after reading in the page).  You have to make sure
that the cycle is really allowed to go through (e.g. the page table entry
is valid and allows reading and writing), otherwise this will cause an 
endless loop.  Doing this in the bus error handler fixes the problem and
should be transparent to the rest of your system.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
(C) Copyright 1986 by John Gilmore.             May the Source be with you!