Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!sun!idi!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.micro.68k,net.micro.16k
Subject: Re: Re: Re: Bus Error Effluvia
Message-ID: <69@intelca.UUCP>
Date: Thu, 12-Sep-85 02:28:34 EDT
Article-I.D.: intelca.69
Posted: Thu Sep 12 02:28:34 1985
Date-Received: Sat, 14-Sep-85 17:08:03 EDT
References: <124@desint.UUCP> <5913@utzoo.UUCP> <44@l5.uucp> <1614@druil.UUCP> <57@intelca.UUCP> <526@oakhill.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 57
Xref: watmath net.micro.68k:1118 net.micro.16k:386

Ok, here is an example of what I think is a problem, pardon the pidgin
assembly language.  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, since (if r0 is used to
pass back values)

loop:
	mov	to-fault-location,blah
	cmp	r0,1
	jnz	loop

will cause problems if the fault happens after the compare (which is
very valid, since the write is pipelined).  As far as I know, the compare
could be done even before the write bus cycle is started!  In this case,
I think all that would happen is that you would get a possibly unnecessary
write after you return from the fault handler.  Is this
important?  I haven't the foggiest, and there probably are ways around
it.  Why I think this has to do with data caches is just that you have
more internal state to work with that could possibly contain stale data
with the execution of instructions going so far beyond the qualification
of bus cycles.  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.

Maybe I'm dense, but I don't think this is at all related to breakpoints/
etc., since these puppies will always cause the break exactly between
instructions, not leaving part of the next instruction or instructions
partially executed.  As far as I can tell, with the 68020, a bus
fault could happen in one HLL instruction, but not be signalled until
the next instruction (or the one 15 instructions down the road).
In addition, you might want to break up the
seemingly atomic code sequences that a compiler generates if you have
a bug in your code somewhere.  Regardless, when you restart the
processor, it is going to do the next instruction working with data
that you may have just modified.  It's not going to start 10 instructions
down the way and ignore any changes that you have made to the data or
the internal state that could have changed the results of the execution
of those 10 instructions.  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?)  The way I think about it,
when you trap the processor write where does the monitor say the
processor is?

Finally, this (and anything that I would say) certainly should not
be taken as a dig on the 68020.  From all I can tell, it seems a
fine machine, and a tremendous engineering accomplishment.
-- 
...and I'm sure it wouldn't interest anybody outside of a small circle
of friends...

Ken Shoemaker, Microprocessor Design for a large, Silicon Valley firm

{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.  They may not represent those of the
	employer of its submitter.