Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!ihnp4!inuxc!pur-ee!uiucdcs!parsec!ctvax!uokvax!andree From: andree@uokvax.UUCP Newsgroups: net.arch Subject: Re: Re: Complement Arithmetic - (nf) Message-ID: <5260@uiucdcs.UUCP> Date: Mon, 30-Jan-84 23:19:04 EST Article-I.D.: uiucdcs.5260 Posted: Mon Jan 30 23:19:04 1984 Date-Received: Tue, 7-Feb-84 06:43:46 EST Lines: 33 #R:burdvax:-142500:uokvax:9900006:000:1517 uokvax!andree Jan 29 13:44:00 1984 My thanks to all those who replied to my query on ones complement vs. twos complement, whether by mail or by news. Most everybody pointed out the infamous extra zero problem. This I know about, and will discuss later in the article. Several people pointed out that it takes extra hardware to do ones complement. I hadn't known this. Considering the earlier discussion on RISC machines, it would seem that this is no longer a problem, but a design consideration. The problem with extended precision arithmetic is also new to me. It looks like this is the only really good reason not to use ones complement. Now, about that extra zero. I think that that's an advantage, not a problem. My inspiration is the PDP-11 floating point. In this, as in many floating point systems, there are a LOT of zeros. The people at DEC did something bright with them. Anything zero except the one with a zero exponent is an illegal value, and can cause a trap. It seems to me that this would be good thing to do with that extra zero in ones complement. Of course, this would involve extra hardware - checking for that on input to arithmetic ops, turning it into the other zero on output, and maybe more. As a software person, this idea appeals to me. Compilers that can check for uninitialized variables at run time? With no bogus values to trip over, and no extra cost? Sounds good to me. Would someone comment on how much extra pain this would be in hardware? I'll go away and think about the extended precision problem.