# Do you use any computer based tool for doing project layout?

Page 6 of 11
• posted on April 13, 2010, 12:35 pm
On Apr 13, 1:33 am, Puckdropper <puckdropper(at)yahoo(dot)com> wrote:

Not true. The (add and subtract) operations use the same logic. Now, multiply and divide are a whole different kettle...

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 13, 2010, 9:40 pm

Really? I've -never- seen an IC chip that did subtraction directly. 'Adder' chips, however, are common as dirt.
You can -accomplish- subtraction using an 'adder' and a bunch of inverters on the second input (and ignore the overflow).
True 'subtract' logic _is_ more complicated -- because the states in the operation table do not collapse as well. Addition: operand1 OR operand2 == 0 => zero result, zero carry operand1 XOR operand2 == 1 => one result, zero carry operand1 AND operand2 == 1 =? zero result, one carry
Subtraction: operand1 EQ operand2 => zero result, zero borrow operand1 EQ 1 AND operand2 EQ 0 => one result, zero borrow operand1 EQ 0 AND operand2 EQ 1 => one result, one borrow
To expound on the 'difference' between addition and subtraction, consider hardware that uses "ONES COMPLEMENT" arithmetic. Where the 'negative' of a number is represented by simply inverting all the bits of the positive value. e.g. the negative of "00000010" is "11111101".
Note well that in _THIS_ number representation scheme there are *TWO* bit- values that evaluate to -zero-. "0000000' is 'positive zero, and '11111111' is 'negative zero'.
It is *HIGHLY*DESIRABLE* that numeric computations which give a "zero" result, have the bit-pattern of 'positive zero'. If you 'subtract' '00000011' from '00000011' by 'complement and add', you get '00000011' +'11111100' ========== '11111111' which is 'negative zero'
if you do it by 'actual' subtraction '00000011' -'00000011' ========== '00000000' which is 'positive zero', the desired result
To get the 'desired result' of 'positive zero', using _adder_ circuitry, one has to have an additional stage that examines -every- result for the 'negative zero' bit-pattern, and inverts all the bits.
The 'does addition by complement and subtract' was *NOT* unique to the CDC machines. *every* machine that used "1's complement" arithmetic internally did things the same way.
There are advantages to "1's complement" over "2's complement", notably _all_ numbers have a positive and negative representation. (In 2's complement math, it is *NOT*POSSIBLE* to represent the complement of the 'largest possible negative negative number'. you _can_ have '-2**n' but only '+((2**n)-1)'. The disadvantage is that there are -two- values for 'zero'. But that's just 'nothing'. <grin>
On the other side of the fence, there _are_ advantages to "2's complement", notably that all numbers have a single _unique_ representation. The disadvantages are that there =is= a negative value that you cannot represent as a positive number. And 2's complement math _IS_ just a little bit slower -- by one gate time -- than 1's complement. As processor speeds became faster, that 'one gate time' difference became less significant, and the world settled on _not_ dealing with "+/- zero".

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 1:36 pm
On Apr 13, 4:40 pm, snipped-for-privacy@host122.r-bonomi.com (Robert Bonomi) wrote:

Really. Really? You haven't looked very hard. http://www.onsemi.com/pub_link/Collateral/MC10H180-D.PDF

...which are the same operations.

So what? Are you trying to prove your prowess with useless information?
<snipped useless '1's complement stuff>

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 1:56 pm

Are you showing off that the information is useless to YOU because your prowess is so elevated?

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 3:46 pm

Idiot. A particular method of encoding negative numbers isn't relevant when discussing the difference/similarity between subtraction and addition. I wouldn't expect you to know anything about it. OTOH, you are up to your usual standards in cashing checks with your mouth that you ass can't cover.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 5:05 pm
Idiot. A particular method of encoding negative numbers isn't relevant when
FWIW, and I won't wish to get dragged into any muck, the algorithm for performing of translating to negative numbers (assuming 2s complement representation) IS relevant if one will evaluate expressions of the form A-B as A+(-B).
Since bitwise negation can be performed by a single transistor, I would expect that that a value in a register could be negated VERY fast. I think just a few clock cycles.
Bill

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 6:02 pm

Above you use 2's complement representations in your example. Now you switch tracks to 1's complement representation of negative numbers (the only format where negation = inversion). Yes, bitwise *INVERSION* can be done by a single transistor (indeed it takes zero clock cycles to invert a signal), but this is a negation only if you're doing 1's complement arithmetic. You still have to do the end-around carry for the addition (two carry propagations). OTOH, if you're doing 2's complement arithmetic negation is invert AND ADD ONE, which also takes two carry propagation periods (complement, add). TANSTAAFL.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 11:10 pm

Above you use 2's complement representations in your example. Now you switch tracks to 1's complement representation of negative numbers (the only format where negation = inversion). Yes, bitwise *INVERSION* can be done by a single transistor (indeed it takes zero clock cycles to invert a signal), but this is a negation only if you're doing 1's complement arithmetic. You still have to do...
That must be one of the reasons they switched to 2s complement, no?

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 11:16 pm

I hate to answer my own question, but the main reason was the duplicity of zeros in 1s complement, I think.
Bill

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 15, 2010, 3:32 am

Mainly, but the uncertainty of the wrap-around-carry doesn't help. I mot sure whether some of the fancier adders (carry look-ahead, carry save, etc.) work well for 1's complement, either (again, the wrap-around issue). Your observation on the two zeros is spot on, however. That takes an additional operation in the critical path of most calculations.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 15, 2010, 10:40 pm

The 'ambiguous' bit-pattern for 'zero' *was* _the_ compelling reason that IEEE 'standardized' on 2's complement. The 'test for zero/non-zero' operation had to check for _two_ bit patterns (all zeroes, all ones), which either took twice as long as a single check, *or* used up a _lot_ more 'silicon real-estate'. Even _worse_, a test for "equality" could not simply check for a bit-for-bit correspondence between the two values, it had to return 'equal' IF one value was all zeroes, and the other was all ones. This was _really_ "bad news" for limited-capability processors -- you had to invert one operand, SUBTRACT, and _then_ perform the zero/non-zero check described above. Suddenly the test for 'equal' is 3 gate times *SLOWER* than a 'subtract'. This _really_ hurts performance. "Inequality" compares are also adversely affected, although not to the same degree.
For *big*, 'maximum performance' machines, the cost of the additional hardware for dealing with unique +0/-0 was small enough (relative to the _total_ cost of the machine) that it was easy to justify for the performance benefits. When the IEEE stuck it's oar in, 'budget' computing was a fact of life -- mini-computers, and micro-processors. It was _important to the *user* of computing that the results on 'cheap' hardware match *exactly* that obtained from using the 'high priced spread'. And that _code_ developed on one machine run *unchanged* on another machine, and produce exactly the same results.
At the vehement urging of the makers of 'budget' computing systems, as well as the users thereof, 2's complement arithmetic was selected for the IEEE standard, *despite* the obvious problem of a _non-symmetric_ representation scheme. Number 'comparisons' were much more common in existing code than 'negations', thus it 'made sense' to use a representation scheme that favored the 'more common' operations. In addition, the 'minor problem' of the 'most negative number' not having a positive counterpart was not perceived to be a 'killer' issue. "Real-world" data showed that only in *VERY*RARE* situations did numeric values in computations get 'close' to the 'limit of representation' in hardware.
I *understand* the decision, although, still to this day, I disagree with it. <wry grin>

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 16, 2010, 12:38 am
data showed that only in *VERY*RARE*

I think some would say that if your variables are getting close to their limits very often, then it's time to consider looking for a new data structure.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 15, 2010, 10:11 pm

The "standard' algorithm, in computer _hardware_ for getting the 2s complement 'negative' of a value is to invert the bits (1's complement negative) and _ADD_1_ to that value. This algorithm, as does *any* other possible algorithm, *fails* when the value to be negated is the 'most negative value' that can be represented on the machine.`

Yup. on a 2's complement machine, "NOT" (1's complement negate) is *much* gaster than "NEG" (2's complement negate). On a 1's complement machine, the opcodes are synonyms (if the latter code even _exists_, that is).

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 8:21 pm

Yup, you're one of 'them' alright. You ain't much.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 8:30 pm

=> zero result, zero borrow

=> one  result, zero borrow

=> one  result, one  borrow

What a moron, RoboTwat, but I already knew that.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 14, 2010, 9:24 pm

m> wrote:

=> one  result, zero carry

=> zero result, zero borrow

=> one  result, zero borrow

=> one  result, one  borrow

Yup, you're right to the core. I find it interesting that the bulk of your comments are degrading and condescending to justabout anybody here. You must really think you're something. Welll... I'm here to tell you that you are not nice.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 15, 2010, 3:33 am
wrote:

Better than being a leftist loser, so yes, I am right.

I don't give a flying fuck what *you* think. You, in particular. Moron.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 15, 2010, 12:07 pm
On Apr 14, 11:33 pm, " snipped-for-privacy@att.bizzzzzzzzzzzz"

)com> wrote:

=> one  result, zero carry

=> zero result, zero borrow

Oh, I see... a liberal.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 15, 2010, 1:29 pm

ot)com> wrote:

=> zero result, zero carry

I know you're stupid. You don't have to constantly demonstrate the fact.

âœ–
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
• posted on April 15, 2010, 1:39 pm
On Thu, 15 Apr 2010 06:29:11 -0700 (PDT), " snipped-for-privacy@gmail.com"

You mean in the same way you demonstrate how to be a red neck?