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.