Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Living With Old Baggage
Keywords: 68040 CAS2
Message-ID: <12741@pt.cs.cmu.edu>
Date: 21 Apr 91 21:05:27 GMT
References: <336@scorpio.gtephx.UUCP>
Organization: Carnegie Mellon
Lines: 27

In article <1991Apr12.001324.5@ux1.cso.uiuc.edu>
	msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) writes:
>The problem is that you will have to include those instructions in the
>next version of your processor in order to remain binary compatible,
>and if things work out differently, as they probably will, they may be
>hard to implement.

In article <336@scorpio.gtephx.UUCP> robertsw@scorpio.UUCP
	(Wild Rider) gives the 68020 "callm"/"rtm" as examples.

An example they weren't able to dump was "cas2". This fetches two
independant words, and then conditionally overwrites them, with one
big R/M/W lock on memory during the whole 4 memory cycles.

Since each of these words could be unaligned, there could be four
page faults just in fetching them. (Let's not even talk about
write-protected/copy-on-write pages.) The 68040 team didn't want to
leave memory locked for a potentially long period, and yet releasing
the lock logically implies a full restart. So, before attempting the
reads, the 68040 insures that all 1-4 mappings are in the TLB and
valid. That's not as trivial as it may sound: the design has to allow
for (say) the 4th mapping bumping the 3rd one back out of the TLB.

The chip works, but I believe they regret getting themselves into
this.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Robotics Institute