frankr@oz.UUCP (Franklin Reynolds) (10/17/86)
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. I realise that the M68030 doesn't exist yet, but maybe someone at Motorola would know about relevant plans. Franklin Reynolds EnMasse Computer Corp. decvax!linus!alliant!enmasse!frankr seismo!harvard!rclex!enmasse!frankr (The opinions expressed above are my own.)
gnu@hoptoad.uucp (John Gilmore) (10/17/86)
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!