Path: utzoo!attcan!uunet!swlabs!jack From: jack@swlabs.uucp (Jack Bonn) Newsgroups: comp.arch Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!] Message-ID: <1990Jun2.091056.12674@swlabs.uucp> Date: 2 Jun 90 09:10:56 GMT References: <1990May27.110726.17007@xavax.com> <1990May28.124724.24879@phri.nyu.edu> Reply-To: jack@swlabs.UUCP (Jack Bonn) Organization: Software Labs, Ltd. Lines: 27 In article <1990May28.124724.24879@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes: >aglew@dwarfs.csg.uiuc.edu (Andy Glew) writes: > No, this is the sort of thing which comes from having write-only >and read-only registers share the same bus address. Even on machines with >very small I/O address spaces (4k on the pdp-11, I think it was) I never >saw a configuration where you came close to filling the I/O address space. Actually, if a read-only and write-only register share the same address, the clear instruction works properly (as long as the read-only register has no side effects). It is only when the write-only register is at a unique address that the strange behavior of the CLR instructions becomes apparent. And even then, sometimes only after some head scratching over an emulator trace (tracing before the bus time out). I agree that cleaner device register definitions like this would be a big improvement. Being able to read what was last written would be a clear win in situations where you have to restore a register as part of clean up. But the worst case I have seen of false "chip shaving" was in a Z80 controller for a communications device. It had an 8K ROM segment that was split into two non-adjacent 4K segments. The responsible hardware engineer indicated that they "saved half a chip" by doing it that way. Lots of shuffling and relinking was the obvious firmware result. -- Jack Bonn, KC1UH, <> Software Labs, Ltd, Box 451, Easton CT 06612 uunet!swlabs!jack (UUCP) jack%swlabs.uucp@uunet.uu.net (INTERNET) jack@kc1uh (TCP/IP) kc1uh@wb1cqo (AX.25)