I've been programming for what, 40 years or so? But I still get stumped by what should be stupid simple things.
Like twos-complement representation of numbers.
OK, in another thread we were discussing how to take the absolute value of a number. I posted this well-known method (I think I saw it in one of Raymond Chen's blog posts):
cdq
xor eax, edx
sub eax, edx
It seems to work. However, it also seems to fail on at least one value:
abs(2147483647) (7FFFFFFFh) = 2147483647
abs(-2147483648) (80000000h) = -2147483648
abs(-2147483647) (80000001h) = 2147483647
abs(-2147483646) (80000002h) = 2147483646OK, review for dummies (me) here:
- The largest signed 32-bit number is 2147483647, right?
- The smallest signed 32-bit number is -2147483648, right?
So why does this
abs() method fail on that smallest value?
It works on the next-largest value (-2147483647).
I'm using
wsprintf() to display this stuff, using
%d for the decimal values. So is it 1) showing the wrong value for
abs(-2147483648), or 2) is my
abs() failing on this value?
Signed,
Puzzled
OK, glimmer of understanding here:
If we're trying to take abs(-2147483648), that means the expected result will be 2147483648, right?
Except that that's larger than the largest valid signed 32-bit number (2147483647). So we can't do that.
So how is it that we cannot get the absolute value of the smallest signed 32-bit number? Doesn't that leave a hole in the whole scheme?
I can make it "work" in my testbed program by using %u instead of %d to display the result. But that's cheating, right?
All this signed/unsigned business is making my head spin ...
... unless we always treat the result of abs() as an unsigned number ...
HEX((maxed positive x 2) + 1 element(0)) = FFFFFFFF <~ Cap on Abs()
not value but size..
OK, I think I've got it figured out:
"My" abs() works fine:
abs PROC
CDQ
XOR EAX, EDX
SUB EAX, EDX
RET
abs ENDP
The result should be interpreted as an unsigned value.
The case of abs(80000000h) is kind of an anomaly:
The result of the function in this case is exactly the same as the input.
This is the one value where the absolute value of the input is outside the range of valid signed numbers; in other words, it's not "reversible".
With all other values you can negate them and end up with a valid signed value.
That doesn't work with this one value.
Amiright?
I know how two complement work,because exercises in electronic class build circuits based on nand gates that does add and modify it to does sub
After already have add,sub is made by adding two complement circuitry to adder circuitry
Pong and breakout is easier with x86 neg when bouncing,6502 had no neg opcode
Quote from: NoCforMe on May 26, 2024, 09:37:51 AMThe case of abs(80000000h) is kind of an anomaly:
The result of the function in this case is exactly the same as the input.
This is the one value where the absolute value of the input is outside the range of valid signed numbers; in other words, it's not "reversible".
With all other values you can negate them and end up with a valid signed value.
That doesn't work with this one value.
Amiright?
Yes, that's right.
That is the one disadvantage of two's complement -- it's asymmetry. The main advantage is one zero value. To make a symmetric representation, you add a minus zero, giving you two zero values.
Thank you; your reply is appreciated.
I was starting to wonder if this whole thread was just a monument to my stupidity. Apparently I'm not as dumb as I thought ...
Quote from: NoCforMe on May 26, 2024, 06:19:36 AMI've been programming for what, 40 years or so?
Wow, that is awesome.
In the early 80s, programming became widespread with the advent of personal computers.
EDIT:
BASIC and Pascal was used in programming courses at that time, when i was at technical school, 81 - 83.
Assembly programming course was with Motorola 6800 system.
Just too long to remember those old things.
My introduction to computing was on a mainframe (Univac), ca. 1982. BASIC.
For those who may not have seen or remembered some of my old posts, my introduction to computing goes back to the early 70's. From a technical point of view it would have been on a main frame, but accessed through timeshare terminals using the Fortran language. My only purpose at the time was to write a program for a warehouse inventory control.
The next attempt at programming was much later when I purchased a TRS-80 in a garage sale back in 1985. It came with a book for the Basic language but I soon discovered "machine language" which was running so much faster that I was sold to assembly for the rest of my life. After buying a PC-XT, it was 16-bit DOS at first but later convinced by Hutch to go for 32-bit MASM.
Now way too old to get involved with 64-bit systems. :sad: :sad: :sad:
Quote from: raymond on May 29, 2024, 02:19:45 AMNow way too old to get involved with 64-bit systems. :sad: :sad: :sad:
No need to be sad you x87 expert : 80 bit bigger than 64 bit :)
I've said it before and I'll say (write) it again:
64-bit programming for me and I think it's safe to say a lot of the other coders around here is total overkill. Completely unnecessary and not worth the additional headaches and hassles.
I exempt the few professionals here who depend on 64-bit coding for their livelihood or for special programming needs (huge datasets, etc.). But for the rest of us, it's just not needed.
Hell, even 32-bit is overkill for a lot of the stuff I do (and I imagine what others here code). Sometimes a little-bitty 8-bit µprocessor is all that's needed to do the job.
Quote from: daydreamer on May 29, 2024, 04:08:19 AM80 bit bigger than 64 bit :)
Yep, we owe lots of precious stuff to Raymond :thumbsup:
I got introduced to programming with the Commodore 64. The manual showed you how to program in BASIC but I did not stick with it though and wish I did.
Quote from: NoCforMe on May 29, 2024, 04:36:07 AMI've said it before and I'll say (write) it again:
64-bit programming for me and I think it's safe to say a lot of the other coders around here is total overkill. Completely unnecessary and not worth the additional headaches and hassles.
I exempt the few professionals here who depend on 64-bit coding for their livelihood or for special programming needs (huge datasets, etc.). But for the rest of us, it's just not needed.
Hell, even 32-bit is overkill for a lot of the stuff I do (and I imagine what others here code). Sometimes a little-bitty 8-bit µprocessor is all that's needed to do the job.
Its more worth it with 128+ bit SIMD to make things go faster,much code before worked on on!y 8 bit or 16 bit,worth investigation, because 8 bit code ported to 128 bit SIMD run faster than 32 bit code ported to 128 bit only 4 times faster
Magnus, SIMD would be even more overkill for the programming I do. No thanks.
Quote from: NoCforMe on May 30, 2024, 09:43:27 AMMagnus, SIMD would be even more overkill for the programming I do. No thanks.
That's my kind of fun,others like gp register code,others fpu,others like opengl /d3d code,others like make masmbasic or their own assembler ...