saturated binary/hex addition

This is a discussion on saturated binary/hex addition within the A Brief History of Cprogramming.com forums, part of the Community Boards category; does anyone know how to do it. if so, can you PLEASE explain thanks!...

  1. #1
    Registered User
    Join Date
    Dec 2002
    Posts
    221

    saturated binary/hex addition

    does anyone know how to do it. if so, can you PLEASE explain

    thanks!

  2. #2
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    What do you mean by "saturated"?

  3. #3
    Registered User
    Join Date
    Dec 2002
    Posts
    221
    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

  4. #4
    Registered User
    Join Date
    Dec 2002
    Posts
    221
    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

  5. #5
    Registered User axon's Avatar
    Join Date
    Feb 2003
    Posts
    2,572
    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

  6. #6
    Registered User axon's Avatar
    Join Date
    Feb 2003
    Posts
    2,572
    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

  7. #7
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    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
    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.

    (note link might change if he updates his notes)
    http://www.drtak.org/teaches/ARC/cis...ok/node51.html

  8. #8
    Registered User
    Join Date
    Dec 2002
    Posts
    221
    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

  9. #9
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    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.
    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.
    Last edited by Thantos; 03-09-2004 at 01:11 AM.

  10. #10
    Registered User
    Join Date
    Dec 2002
    Posts
    221
    THANK YOU!!!!!

  11. #11
    Registered User
    Join Date
    Dec 2002
    Posts
    221
    1110b + 0010b = 1000b (limited to 4 bits) = 0000b


    how about 1100b + 1111
    would that equal 0000b? or 1011?

    im thinkin 0000b on this one

  12. #12
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Wells lets try it out and see
    Using code tags to preserve spacing
    Code:
     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

  13. #13
    Registered User
    Join Date
    Dec 2002
    Posts
    221
    thank you very much
    i think i got it

  14. #14
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 06-01-2008, 08:47 AM
  2. Repeated Addition
    By rocksteady in forum C Programming
    Replies: 15
    Last Post: 12-11-2007, 07:05 AM
  3. need some help with binary addition.
    By InvariantLoop in forum C++ Programming
    Replies: 21
    Last Post: 01-27-2005, 06:52 AM
  4. Problems with an addition operator
    By jamjar in forum C++ Programming
    Replies: 12
    Last Post: 03-28-2003, 01:47 PM
  5. addition
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 01-19-2002, 07:53 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21