PDA

View Full Version : saturated binary/hex addition

revelation437
03-09-2004, 12:09 AM
does anyone know how to do it. if so, can you PLEASE explain

thanks!

Thantos
03-09-2004, 12:10 AM
What do you mean by "saturated"?

revelation437
03-09-2004, 12:18 AM
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

revelation437
03-09-2004, 12:23 AM

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

axon
03-09-2004, 12:24 AM
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?

axon
03-09-2004, 12:26 AM

Thantos
03-09-2004, 12:55 AM

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
FFFFh + 0001h = 10000h

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.

http://www.drtak.org/teaches/ARC/cisp310/book/book/node51.html

revelation437
03-09-2004, 12:56 AM
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

Thantos
03-09-2004, 01:08 AM
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

since adding 1 more to 15 would cause it to roll over, it maxes out at the biggest number
In case you didn't understand: The number will roll over and those digits will be lost (unless you know asm).
Only way to keep it from rolling over is to setup some checking inside a program.

revelation437
03-09-2004, 01:27 AM
THANK YOU!!!!!

revelation437
03-09-2004, 01:39 AM
1110b + 0010b = 1000b (limited to 4 bits) = 0000b

would that equal 0000b? or 1011?

im thinkin 0000b on this one

Thantos
03-09-2004, 01:52 AM
Wells lets try it out and see
Using code tags to preserve spacing

1100b
+1111b
_____
0011
11
_____
11011

The second line of numbers under the ___ is the carry line. So 1+1 = 0 with a carry.

So 1100b + 1111b = 1011b when limited to 4 bits

revelation437
03-09-2004, 02:00 AM
thank you very much
i think i got it

VirtualAce
03-09-2004, 06:11 PM
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.