Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: more Observability
Message-ID: <5945@pt.cs.cmu.edu>
Date: 23 Aug 89 02:28:45 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 47

While I'm on the subject of knowing what one's system is, and does:

In article <9786@alice.UUCP> jmk@alice.UUCP (Jim McKie) writes:
>	The timer is both readable and writeable, and the 
>	counting function is controlled by the low three bits, which are
>	write only.

Oh, dear. Write only registers, again.

This used to be an extremely common practice in device interfaces,
and in most of the early LSI. It was aften a royal pain.

The offending designers usually come back with "but you set it! Just
remember what value you set it to!". This is a lousy answer.

The value may be wrong because the algorithm that sets it needs
debugging.

The value may be wrong because we (or someone else) didn't understand
the !@#$& manual. This was particularly likely when a mode could only
be established through some sequence of writes, rather than through a
single write.

The value may be wrong because the chip is wrong. Leaving aside
the sad history of "sample" chips, there have always been production
chips on the market with more-or-less obscure design bugs.

The value may be wrong because the software was interrupted.

The value may be wrong because there are multiple masters. I have sad
memories of an intelligent terminal whose modes could be adjusted by
its operator. The handler software couldn't know he'd done it, and
couldn't ask the hardware what its modes were. This was software
running on pure faith. (Actually, it would have been running on
faith, except that we never got it running. By the time we understood
the !@#$& manual, the terminal had croaked.)

The value may be set by software which is attempting to restore a
previous mode. (The classic sequence is: sample mode: change mode:
compute: restore previous mode. I will leave aside the famous problem
of getting interrupted just after the sampling step.) In this case,
the "but you know what you set it to!" comeback is a statement that
the software is monolithic. Why should I have to communicate values
to the corners of the earth? Why can't I write the clear,
easy-to-prove routine that samples/sets/restores?
-- 
Don		D.C.Lindsay 	Carnegie Mellon School of Computer Science