[net.micro.68k] Bus Error Effluvia, ICE operation, etc.

gnu@l5.uucp (John Gilmore) (09/20/85)

In article <69@intelca.UUCP>, kds@intelca.UUCP (Ken Shoemaker) writes:
>                     If you have the processor in a polling loop, and you
> know that either to get out of the loop you'll get a memory fault on a
> write, and the status of that fault will be returned in a register by the
> bus fault handler, you have to be very careful...

He's right; you have to be very careful.  This is a highly
processor-dependent operation.  Can you run the same code (and fault
handler) on an 8086 and an 80286 and an 80386?  (You can't on 68000,
68010, and 68020.)  You're going to have to change a few things to
upgrade to a new chip (anywhere in a system, not just the CPU).  The
idea is to make the changes only affect the kernel hackers, leaving the
user code running compatibly.  A kernel hacker experienced in porting
would probably not write a loop that only exits when it gets a bus
error, by passing funny values back in registers -- or s/he would expect
it to break during a port.  A good hardware designer would not design
hardware that ends a polling loop by giving a bus error when it has
no data.

I believe the way Unix handles such things is by having a global
variable ("lofault") that gives a place to jump to when a bus error
occurs.  When we want to test accessability of a virtual address, we
set that to point to a routine that returns a "bad address" value.  The
main routine just makes the access and returns the "good address"
value.  We never have to try to resume the code that was running at the
time of the bus error; we just run alternate code.  There are still
possible problems here, and this is an area that needs looking at when
porting to new processors, like most of the MMU-related code.

>                 The easy way out is just to not allow concurrent data
> accesses to the internal data cache while there are outstanding requests
> on the external bus.

This sounds like a possible bottleneck; what does it really buy you in
practical operation?  It lets you avoid carefully reading your bus error
handling code?  I'd trade a careful read for a 3% performance increase...

>                            But thinking about debuggers, doesn't
> this little 68020 feature cause problems if you want to trap
> on a write to memory (ala an ICE unit?)

I recall a sentence in the IBM 370 "Program Event Recording" section of
the manuals.  (PER is a facility that gives access to breakpoint style
hardware.)  It was something on the order of "turning this on makes the
machine run a lot slower".

The 68020 provides ways for an ICE to turn off the internal cache and
to single step or single-instruction the processor, as well as insert
breakpoints.  These ways almost all involve slowing down the processor
so the ICE can see what it is doing.  I'm happy to run in "fast mode"
99% of the time and run in "debug mode" the rest.