kaufman@neon.Stanford.EDU (Marc T. Kaufman) (05/25/91)
In article <1991May24.213815.16227@midway.uchicago.edu> tisu@quads.uchicago.edu (Seth Tisue) writes: >For class, I'm writing a four-function stack-based calculator in >assembly language. The program uses 32-bit signed integers. My >question concerns the overflow bit of the status register. Here's the code: deleted... >This code works as expected for all but one case. >Suppose the two items popped off the stack are $80000001 and $00000001 -- >i.e., in decimal, the function to be performed is (-2147483648) minus one. >Since that number is the most negative number you can fit into 32 bits, >it seems to me that this should generate. However, it does NOT generate >an overflow (I've stepped through w/MacsBug and checked), and the answer >returned is $80000000, which is meaningless ("negative zero"). Sigh! What kind of class is this where they don't explain the difference between 1's complement, 2's complement, and sign-magnitude representations? The native mode of a 68000 for instance is 2's complement. In that mode, $80000001 = -2147483647, and that minus 1 gives $80000000 - -2147483648. Yes, it is the case that there is no representation in 2's comp form of the positive number +2147483648 (at least in 32 bits). In 1's complement and sign-magnitude notation there are, indeed, 2 representations of zero (+0 and -0), and the positive and negative ranges are symmetric. But you don't have that, in terms of the 68000 Flag bits at least. Marc Kaufman (kaufman@Neon.stanford.edu) [a believer in the principle that there should be no such thing as an UNDERGRADUATE CS major]
tisu@quads.uchicago.edu (Seth Tisue) (05/26/91)
In article <1991May25.021530.17126@neon.Stanford.EDU> kaufman@neon.Stanford.EDU (Marc T. Kaufman) writes: >Sigh! What kind of class is this where they don't explain the difference >between 1's complement, 2's complement, and sign-magnitude representations? >The native mode of a 68000 for instance is 2's complement. In that mode, >$80000001 = -2147483647, and that minus 1 gives $80000000 - -2147483648. >Yes, it is the case that there is no representation in 2's comp form of the >positive number +2147483648 (at least in 32 bits). > >In 1's complement and sign-magnitude notation there are, indeed, 2 >representations of zero (+0 and -0), and the positive and negative ranges >are symmetric. But you don't have that, in terms of the 68000 Flag bits >at least. Thanks to everyone who straightened me out on this. It still seems like a poor situation to have a negative number, -214783648, which has no valid corresponding positive representation; I'll have my program check for it. (I don't think the user should have to worry about taking the negative of something yield an overflow.) >[a believer in the principle that there should be no such thing as an >UNDERGRADUATE CS major] You'd be happy here at the University of Chicago; there's no CS major here. You have to major in "Applied Math" (grr) and then take computer courses. -- ---- Seth Tisue USMail: c/o Plaster Cramp Press ---- (tisu@midway.uchicago.edu) P.O. Box 5975 "Please to be restful. It is only a few Chicago IL 60680 crazies who have from the crazy place outbroken." --------------
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (05/26/91)
Seth Tisue writes in a message to All
ST> Thanks to everyone who straightened me out on this. It still
ST> seems like a poor situation to have a negative number, -214783648,
ST> which has no valid corresponding positive representation; I'll
ST> have my program check for it. (I don't think the user should
ST> have to worry about taking the negative of something yield an
overflow.)
Think about it: you have 2^32 numbers available (an even number), this gives
one either an equal number of positive and negative numbers and 2 possible zeros
(one's compliment) or an even number of negative numbers, an odd number of positive
numbers and only one zero (two's compliment). It seems to me that the average
"user" would worry more about the existance of two zeros than about the imbalance
of positive and negative. After all, one might have (and ofen does) a use for
that last odd number, but how many times do you need a second way of representing
"zero?" And for that matter, imagine the headaches of the chip designer who
must add a second test for zero if one's compliment arithmatic were standard.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orggaletti@uservx.afwl.af.mil (05/29/91)
In article <12423.284125F3@stjhmc.fidonet.org>, Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: > Seth Tisue writes in a message to All > > ST> Thanks to everyone who straightened me out on this. It still > ST> seems like a poor situation to have a negative number, -214783648, > ST> which has no valid corresponding positive representation; I'll > ST> have my program check for it. (I don't think the user should > ST> have to worry about taking the negative of something yield an > overflow.) > > Think about it: you have 2^32 numbers available (an even number), this gives > one either an equal number of positive and negative numbers and 2 possible zeros > (one's compliment) or an even number of negative numbers, an odd number of positive > numbers and only one zero (two's compliment). It seems to me that the average > "user" would worry more about the existance of two zeros than about the imbalance > of positive and negative. After all, one might have (and ofen does) a use for > that last odd number, but how many times do you need a second way of representing > "zero?" And for that matter, imagine the headaches of the chip designer who > must add a second test for zero if one's compliment arithmatic were standard. > Yeah, and worse yet, think of the added complexity needed to implement an ALU that has to deal with one's complement. A simple adder can add two positive numbers. The beauty of two's complement is that you can use the same adder to add two negative numbers, or a positive and a negative number, and provided you don't generate an overflow, you get the right answer! The simplest example: Add -1 to a number. In 8-bit one's complement you would have: 10000001 (-1) + 00000001 (+1) You would first have to decide which number is negative, invert the sign bit, move it to the subtrahend field, and then subtract it from the positive number. With two's complement: 11111111 (-1) + 00000001 (+1) You simply add these two numbers and get zero! Of course there are a few tests the ALU must do to generate overflow flags, but they can be done in parallel with the add, and thus no additional delay is incurred. > Lawson > > > -- > Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English > Internet: Lawson.English@p88.f15.n300.z1.fidonet.org -- ___________________________________________________________________________ / Ralph Galetti Internet: galetti@uservx.afwl.af.mil \ | PL/ARCB Interests: computers, music, computers | | Kirtland AFB, NM 87117-6008 and music, golf, sleep. | \______________"I hate cliches--I avoid them like the plague"_______________/
tisu@quads.uchicago.edu (Seth Tisue) (05/30/91)
In article <12423.284125F3@stjhmc.fidonet.org> Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: >Think about it: you have 2^32 numbers available (an even number), this gives >one either an equal number of positive and negative numbers and 2 possible zeros >(one's compliment) or an even number of negative numbers, an odd number of positive >numbers and only one zero (two's compliment). It seems to me that the average >"user" would worry more about the existance of two zeros than about the imbalance >of positive and negative. >After all, one might have (and ofen does) a use for >that last odd number, but how many times do you need a second way of representing >"zero?" And for that matter, imagine the headaches of the chip designer who >must add a second test for zero if one's compliment arithmatic were standard. I wasn't advocating one's complement arithmetic -- I'm not that naive. What I was wondering was, why not have $80000000 (-2^31) be an invalid number rather than -2^31, thus removing the asymmetry? I'm assuming there's some good reason for this... What uses does one "often have" for the extra number? -- ---- Seth Tisue USMail: c/o Plaster Cramp Press ---- (tisu@midway.uchicago.edu) P.O. Box 5975 "Please to be restful. It is only a few Chicago IL 60680 crazies who have from the crazy place outbroken." --------------
kaufman@neon.Stanford.EDU (Marc T. Kaufman) (05/30/91)
In article <1991May29.210531.7174@midway.uchicago.edu> tisu@quads.uchicago.edu (Seth Tisue) writes: >I wasn't advocating one's complement arithmetic -- I'm not that naive. What >I was wondering was, why not have $80000000 (-2^31) be an invalid number >rather than -2^31, thus removing the asymmetry? I'm assuming there's some >good reason for this... What uses does one "often have" for the extra >number? And pray tell, what would you do, special, about this number. How would you set the Flag bits, and how would you modify the CPU arithmetic to deal with it? If the number offends thee, pluck it out. Program tests in your code to deal with it. It's convenient for most of the rest of us that the +1 operation works in a consistent manner for ALL bit combinations. Marc Kaufman (kaufman@Neon.stanford.edu)
kaufman@neon.Stanford.EDU (Marc T. Kaufman) (05/30/91)
In article <1991May29.164914.22930@uservx.afwl.af.mil> galetti@uservx.afwl.af.mil writes:
.Yeah, and worse yet, think of the added complexity needed to implement an ALU
.that has to deal with one's complement. A simple adder can add two positive
.numbers. The beauty of two's complement is that you can use the same adder to
.add two negative numbers, or a positive and a negative number, and provided you
.don't generate an overflow, you get the right answer! The simplest example:
.Add -1 to a number. In 8-bit one's complement you would have:
. 10000001 (-1)
. + 00000001 (+1)
Unfortunately for you, this is Sign/Magnitude notation, NOT 1's complement.
The 1's complement representation is:
11111110 (-1)
+ 00000001 (+1)
.You would first have to decide which number is negative, invert the sign bit,
.move it to the subtrahend field, and then subtract it from the positive number.
.With two's complement:
. 11111111 (-1)
. + 00000001 (+1)
.You simply add these two numbers and get zero! Of course there are a few tests
.the ALU must do to generate overflow flags, but they can be done in parallel
.with the add, and thus no additional delay is incurred.
. ___________________________________________________________________________
. / Ralph Galetti Internet: galetti@uservx.afwl.af.mil \
.| PL/ARCB Interests: computers, music, computers |
.| Kirtland AFB, NM 87117-6008 and music, golf, sleep. |
. \______________"I hate cliches--I avoid them like the plague"_______________/
Tsk, Tsk, Ralph. I thought Kirtland had a Control Data 6600 (or Cyber 70 as
they are called today). Guess what: that is a 1's complement machine. The
arithmetic is no more complicated on a 1's complement machine. If you are
using adders, just take the carry end-around to the low end. The real way
to do 1's complement is to use SUBTRACTERs, as CDC did. That way, the only
time you will get -0 as a result is if you add -0 to -0. Negation is MUCH
faster in 1's complement (exercise left to the student).
Marc Kaufman (kaufman@Neon.stanford.edu)d88-jwa@byse.nada.kth.se (Jon W{tte) (05/30/91)
> tisu@quads.uchicago.edu (Seth Tisue) writes:
I wasn't advocating one's complement arithmetic -- I'm not that naive. What
I was wondering was, why not have $80000000 (-2^31) be an invalid number
rather than -2^31, thus removing the asymmetry? I'm assuming there's some
good reason for this... What uses does one "often have" for the extra
number?
#define _FLAME mild
And spend one extra clock cycle checking for this illegal number
for each instruction ? Are you serious ?
And if the "extra" negative number really bothers you, I suggest
you a) take a week in the countryside or b) see a psychologist.
#undef _FLAME
--
Jon W{tte
h+@nada.kth.se
- Speed !brian@umbc4.umbc.edu (Brian Cuthie) (05/30/91)
In article <1991May30.020707.11193@neon.Stanford.EDU> kaufman@neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <1991May29.210531.7174@midway.uchicago.edu> tisu@quads.uchicago.edu (Seth Tisue) writes: > >>I wasn't advocating one's complement arithmetic -- I'm not that naive. What >>I was wondering was, why not have $80000000 (-2^31) be an invalid number >>rather than -2^31, thus removing the asymmetry? I'm assuming there's some >>good reason for this... What uses does one "often have" for the extra >>number? > >And pray tell, what would you do, special, about this number. How would you >set the Flag bits, and how would you modify the CPU arithmetic to deal with >it? If the number offends thee, pluck it out. Program tests in your code >to deal with it. It's convenient for most of the rest of us that the +1 >operation works in a consistent manner for ALL bit combinations. > >Marc Kaufman (kaufman@Neon.stanford.edu) Worse yet, is that the interpretation of data is context dependent. That $8000000000 could just as easilly be valid as an unsigned number. As far as the processor is concerned, there is no such thing as a positive or negative number. The computations are done exactly the same, the flags are set tha same. In fact, notice that there are not different instructions for doing signed addtion and unsigned addition. The only difference is in the way that you interpret the results and the flags afterwards. For representations that are known, such as floating point, it is possible to have declared illegal values. For instance, on the VAX an F-Floating type represents the exponent as an "excess-128" number. Where 128 becomes a virtual "0" and positive exponents are added to 128 and negative ones are subtracted from it. Obviously, there can be 127 positive exponents and 128 negative ones. However, the -128 exponent (or 0) is reserved to indicate that the number's actual value is zero. This is necessary becauuse of the implied ".1" that leads the fractional part of every floating number on a VAX. But, these restrictions only apply when using floating point instructions. Because they are different instructions, they "know" the data's type and can impose additional rules. The integer instructions have no such luxury (nor do they need it). Anyway, the moral is: You don't know what the data is explicitly. It is completely left to interpretation. Even floating point numbers can look like ASCII. Therefore, there is no good way to cause the processor to forbid certain numbers from existing as integers. -brian
osborn@ux1.lbl.gov (James R Osborn) (05/31/91)
Hey guys, Don't you think this "68000 Assembly question" has gotten out of the spirit of "comp.sys.mac.programmer"? I don't give a flying hoot about whether the mac uses 1's complement or 2's complement, and I never will! 8^( Perhaps you'd care to move your discussion elsewhere.) -- James .------------------------------.--------------------------------------. | James R. Osborn | It just goes to show you it's always | | Lawrence Berkeley Laboratory | something. Either it's baffling | | osborn@ux1.lbl.gov | tech notes or your mac is smoking. | | (415) 548-8464 | It's always something... | '------------------------------'--------------------------------------' (FLAMES AWAY!!!!!)
kaufman@neon.Stanford.EDU (Marc T. Kaufman) (05/31/91)
In article <13745@dog.ee.lbl.gov> osborn@ux1.lbl.gov (James R Osborn) writes: >Hey guys, >Don't you think this "68000 Assembly question" has gotten out >of the spirit of "comp.sys.mac.programmer"? I don't give a >flying hoot about whether the mac uses 1's complement or 2's >complement, and I never will! 8^( Perhaps you'd care to move >your discussion elsewhere.) Gee, and all this time I thought that this group was about PROGRAMMING the Mac. Last I looked, one needed at least a rudimentary knowledge of how data is represented at the bit level. But maybe you are using a high level language, so you don't need to know that kind of stuff. Marc Kaufman (kaufman@Neon.stanford.edu)
osborn@ux1.lbl.gov (James R Osborn) (05/31/91)
In article <1991May31.054322.7297@neon.Stanford.EDU> kaufman@neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <13745@dog.ee.lbl.gov> osborn@ux1.lbl.gov (James R Osborn) writes: >>Hey guys, > >>Don't you think this "68000 Assembly question" has gotten out >>of the spirit of "comp.sys.mac.programmer"? I don't give a >>flying hoot about whether the mac uses 1's complement or 2's >>complement, and I never will! 8^( Perhaps you'd care to move >>your discussion elsewhere.) > >Gee, and all this time I thought that this group was about PROGRAMMING the >Mac. Last I looked, one needed at least a rudimentary knowledge of how >data is represented at the bit level. > >But maybe you are using a high level language, so you don't need to know >that kind of stuff. > >Marc Kaufman (kaufman@Neon.stanford.edu) Boy there sure are some fragile egos out there. TWO personal email replies and a sarcastic post in reply to boot! As long as you guys seem to think that it's ok for your discussion to meander, I think it's ok for me to put in my 2 cents on what I think of your discussion. There is a reason that there are thousands of different news groups - to reduce bandwidth (like this useless post! :-) It's a free country (and world for the most part)! Besides I felt pretty sarcastic myself yesterday... -- James .------------------------------.--------------------------------------. | James R. Osborn | It just goes to show you it's always | | Lawrence Berkeley Laboratory | something. Either it's baffling | | osborn@ux1.lbl.gov | tech notes or your mac is smoking. | | (415) 548-8464 | It's always something... | '------------------------------'--------------------------------------' Gee I'm really sorry if I hurt anybody's feelings...sniff...sniff...
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (06/01/91)
Seth Tisue writes in a message to All
ST> I wasn't advocating one's complement arithmetic -- I'm not that
ST> naive. What I was wondering was, why not have $80000000 (-2^31)
ST> be an invalid number rather than -2^31, thus removing the asymmetry?
ST> I'm assuming there's some good reason for this... What uses does
ST> one "often have" for the extra number?
Why would you want to eliminate a number from the range? It exists as a
natural
consequence of 2's compliment arithmatic. To specify that -2^31 didn't really
exist would take computer languages another step away from the machine without
reason, and require that compiler writers write exception code so that that
number would be invalid, even though it existed at the hardware level. As for
whether "one often has" a use for the extra number, nah... I was being silly.
But the added complexity that eliminating -2^<whatever> would add to a
language
implementation would be rediculous: imagine having to do a range check as well
as an over-flow check whenever you added or subtracted a number... Sloooow.
Someone else has suggested that we drop this. Let's take it to E-mail after
this if we continue.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgLawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (06/03/91)
James R Osborn writes in a message to All
JRO> As long as you guys seem to think that it's ok for your discussion
JRO> to meander, I think it's ok for me to put in my 2 cents on what
JRO> I think of your discussion. There is a reason that there are
JRO> thousands of different news groups - to reduce bandwidth (like
JRO> this useless post! :-)
JRO> It's a free country (and world for the most part)! Besides I
JRO> felt pretty sarcastic myself yesterday...
A new newsgroup:
Comp.Sys.Useless.Post
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgtisu@quads.uchicago.edu (Seth Tisue) (06/05/91)
In article <12977.2847A793@stjhmc.fidonet.org> Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: [lots of two's complement stuff deleted] >Someone else has suggested that we drop this. Consider it dropped -- I got my questions answered. -- ---- Seth Tisue USMail: c/o Plaster Cramp Press ---- (tisu@midway.uchicago.edu) P.O. Box 5975 "Please to be restful. It is only a few Chicago IL 60680 crazies who have from the crazy place outbroken." --------------