does anyone know how to do it. if so, can you PLEASE explain
thanks!
does anyone know how to do it. if so, can you PLEASE explain
thanks!
thats what i wanna know. teacher didnt go over it much at all... and apparently we're being tested on it
it has to be both signed and unsigned.
its nothing like modular math, i get that ish
example of unsigned addition
FFFFh + 0001h = FFFFh
im kinda not understandin the signed as much
im assuming, if it goes over the max pos, it'd be limited to 7FFFh and if lower than the lowest minus, it'd be ffff
i checked in a few places, and can't find anything definitive on the subject...
edit: so are you talking about normal signed/unsigned addition in differnt number bases? if so, wtf is saturated?
some entropy with that sink? entropysink.com
there are two cardinal sins from which all others spring: Impatience and Laziness. - franz kafka
if just operations on different number bases, look here
some entropy with that sink? entropysink.com
there are two cardinal sins from which all others spring: Impatience and Laziness. - franz kafka
FFFFh + 0001h = 10000hexample of unsigned addition
FFFFh + 0001h = FFFFh
im kinda not understandin the signed as much
im assuming, if it goes over the max pos, it'd be limited to 7FFFh and if lower than the lowest minus, it'd be ffff
For the Binary addition have they gone over ones and twos compliment? If not then there is no way to do signed comparisons.
The way my instructor told us to do hex addition/subtraction is just convert to binary and then do it that way. Reason being is that going from binary to hex and back is just pattern matching.
I'm linking his site. It may be a little hard to understand without in the inclass lecture but its worth a shot.
(note link might change if he updates his notes)
http://www.drtak.org/teaches/ARC/cis...ok/node51.html
its not just that
its limitations placed on the addition of signed and unsigned numbers
ie
1111b + 0001b = 1111b
since adding 1 more to 15 would cause it to roll over, it maxes out at the biggest number
now im asking more about the signed than unsigned
The value actually depends.
Lets say you have Eh and add 1h to it. It becomes Fh. Now we add one more it becomes 10h. However say we were limited to 4 bits. Then the value becomes 0h.
In binary:
1110b + 0001b = 1111b + 1b = 10000b but since we are limited to 4 bits we get 0b.
Unsigned gets a lot more complicated. Bit pattern of say -1 with 4 bits is: 1111b
1111b + 0001b = 1000b (limited to 4 bits) = 0000b. -1 + 1 = 0 Simple
bit pattern of -2 with 4 bits:
1110b + 0010b = 1000b (limited to 4 bits) = 0000b
Check out that link and read what he has to say about twos compliment.
In case you didn't understand: The number will roll over and those digits will be lost (unless you know asm).since adding 1 more to 15 would cause it to roll over, it maxes out at the biggest number
Only way to keep it from rolling over is to setup some checking inside a program.
Last edited by Thantos; 03-09-2004 at 01:11 AM.
THANK YOU!!!!!
1110b + 0010b = 1000b (limited to 4 bits) = 0000b
how about 1100b + 1111
would that equal 0000b? or 1011?
im thinkin 0000b on this one
Wells lets try it out and see
Using code tags to preserve spacing
The second line of numbers under the ___ is the carry line. So 1+1 = 0 with a carry.Code:1100b +1111b _____ 0011 11 _____ 11011
So 1100b + 1111b = 1011b when limited to 4 bits
thank you very much
i think i got it
Saturation is defined in Intel's MMX Technology Technical Reference Manual.
There are opcodes in the MMX set that perform saturated adds, subtracts, multiplies, and divides.
Saturation is simply used so the values do not overflow their data type. In graphics this causes big problems and writing clipping for each wastes cycles. So Intel's solution to this was at the CPU level - just don't overflow the data type. It works very well and its very fast.
Unfortunately MMX came out a bit too late and most video cards GPU's are faster than the MMX architecture. But MMX is still good for writing functions that the video hardware does not support or that the DirectX HEL supports, but is far too slow.
Any mathematical operation that would result in overflow or underflow is clipped so that the value does not suffer from wraparound. Unfortunately the bits that are lost are not stored anywhere so that information is discarded - resulting in major precision loss. Moral of the story is don't depend on MMX saturated arithmetic opcodes for accuracy in calculations - they are really for writing multimedia code.
This only applies to unpacked values. For packed values, each individual data type is saturated according to its data type. For instance in a packed BYTE which is 8 bytes - each byte is saturated.
Here is a packed byte add with saturation:
255 255 255 255 255 000 000 255
+
100 010 050 001 002 054 032 017
--------------------------------------------
255 255 255 255 255 054 032 255
FF FF FF FF FF 36 20 FF
or simply
FFFFFFFF3620FF
If this was a packed WORD add with saturation then each word would be saturated to the max and min values of a WORD.
With this opcode you could add two images together in 256 color mode 8 pixels at a time in one instruction w/o having to worry about underflow and overflow. Very powerful.
I'm not sure about the actual rules of saturation arithmetic but in Intel's scheme these opcodes do not affect the carry flags or any of the flags for that matter. Any information that is shifted out of the data type is lost forever. The packed compare functions are the only ones that affect the flags according to my docs.
Last edited by VirtualAce; 03-09-2004 at 06:26 PM.