Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!portal!cup.portal.com!mmm
From: mmm@cup.portal.com (Mark Robert Thorson)
Newsgroups: comp.arch
Subject: Re: more Observability
Message-ID: <21547@cup.portal.com>
Date: 23 Aug 89 20:35:03 GMT
References: <5945@pt.cs.cmu.edu>
Organization: The Portal System (TM)
Lines: 31

This discussion of write-only bits reminds me of an occassion when I was
helping somebody bring up software for a prototype Unibus frame buffer.
He had written some simple code to scribble on the frame buffer, just
to see if it was working and to verify he knew how to address it.  That
code worked fine.

Then he had written some more advanced code to support a decent demo program.
That code didn't work at all.  He finally localized the bug to an XOR
instruction being used to actually perform the write to the frame buffer.
It seemed as though XOR didn't work.

"Maybe the XOR instruction is broken,"  I said.

"That's impossible, the operating system uses XOR.  Nothing would run if
it were broken."  he said.

"Well can't you at least try replacing that XOR with something else?"

After much desperation trying other things, he did that.  He read the frame
buffer, did some operations on it in register, and wrote it back out.  To
his utter amazement, that worked fine.

After a few seconds of thinking about it, I said, "You know, a read cycle
and a write cycle on the Unibus are different from a read-modify-write
cycle.  There's a code on the control lines which indicates a DATIP cycle."
(DATIP is DEC parlance for data-in-pause, which is same as an RMW operation.
This was used for faster access to destructive-read core memory by inhibiting
the write-back of the read data.)

It turned out that the hardware engineering group had not implemented DATIP
cycles, figuring that read and write are enough.