Sign-extension?

Discussion in 'C Programming' started by Sona, Sep 24, 2003.

  1. Sona

    Sona Guest

    Hi,

    Could someone please explain what sign-extension means? If I have a hex
    number 0x55, how does this get sign-extended? Can a sign-extended
    counterpart be equal to -91? In a program I'm expecting 0x55 in return
    from a function whereas I am getting -91 every time.. does this mean
    anything? Thanks

    Sona
    Sona, Sep 24, 2003
    #1
    1. Advertising

  2. "Sona" <> wrote in message
    news:3f71ba78$...
    > Hi,
    >
    > Could someone please explain what sign-extension means? If I have a hex
    > number 0x55, how does this get sign-extended?


    Try asking this question in comp.programming.

    > Can a sign-extended
    > counterpart be equal to -91? In a program I'm expecting 0x55 in return
    > from a function whereas I am getting -91 every time.. does this mean
    > anything?


    It means you are doing something wrong. Hard to tell without more
    context. Gi'us some code. The bit pattern 0x55 is not negative in any
    C integral type I can think of. Try reproducing the problem with as little
    code as possible and post it here.

    --
    Thomas.
    Thomas Stegen, Sep 24, 2003
    #2
    1. Advertising

  3. Sona wrote:
    > Hi,
    >
    > Could someone please explain what sign-extension means?



    Sign extension is usually a low-level (i.e. assembly) processor term.
    In most applications using the C language, there is no concern about
    sign extension as that is accounted for in the definition of the
    language.

    Basically, sign extension is extending the sign of a number (positive
    or negative) from a single unit integer to a multi-unit integer.

    For example, if you have an integer representing 0x55 and wish to
    use two integers (to extend the range), you would set up the second
    integer to be zero, which is the sign for a positive number (not
    true for all platforms). Negativity is a bit different.

    Let us assume for example, that in a given system, -1 is represented
    by all bits set to one. When using two integers, the combination
    must represent -1. So, the second integer is set to all ones to
    extend the sign of the first integer.

    Search for these programming concepts:
    Multiple Precision Arithmetic
    One's Compliment
    Two's Compliment


    > If I have a hex number 0x55, how does this get sign-extended?


    See above.


    > Can a sign-extended counterpart be equal to -91?

    I believe you are confusing sign-extension with signed representation
    of a number.

    In Twos Compliment notation, I am get 0xA5 as -91 (8-bit unit).
    Sign extending to 16-bits results in 0xFFA5, to 32 bits: 0xFFFFFFA5.


    > In a program I'm expecting 0x55 in return
    > from a function whereas I am getting -91 every time.. does this mean
    > anything? Thanks
    >
    > Sona
    >


    I have no idea. There may be an infinite number of relationships
    between -91 and 0x55; Two's Complement negativity isn't one of them.

    Have you tried single stepping through the function with a debugger?
    Or even using printf statements within the function?

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
    Thomas Matthews, Sep 24, 2003
    #3
  4. "Sona" <> wrote in message
    news:3f71ba78$...
    > Hi,
    >
    > Could someone please explain what sign-extension means? If I have a hex
    > number 0x55, how does this get sign-extended? Can a sign-extended
    > counterpart be equal to -91? In a program I'm expecting 0x55 in return
    > from a function whereas I am getting -91 every time.. does this mean
    > anything? Thanks


    You can't get -91 from 0x55 in C.

    In a C implementation where char are signed, and twos complement, -91 would
    be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum of 8
    bits for a char.

    -- glen
    Glen Herrmannsfeldt, Sep 25, 2003
    #4
  5. In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <> writes:
    > "Sona" <> wrote in message
    > news:3f71ba78$...
    > > Could someone please explain what sign-extension means? If I have a hex
    > > number 0x55, how does this get sign-extended? Can a sign-extended
    > > counterpart be equal to -91? In a program I'm expecting 0x55 in return
    > > from a function whereas I am getting -91 every time.. does this mean
    > > anything? Thanks

    >
    > You can't get -91 from 0x55 in C.
    >
    > In a C implementation where char are signed, and twos complement, -91 would
    > be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum of 8
    > bits for a char.


    struct foo {
    signed char foo: 7;
    } foo;

    int main(void) {
    foo.foo = 0x55;
    printf("%d\n", foo.foo);
    }

    But this will print -43, not -91 ;-).
    But (signed char)(0x55 + 0x550) will do the trick if a char is 8 bits.
    --
    dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
    home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
    Dik T. Winter, Sep 25, 2003
    #5
  6. Sona

    Micah Cowan Guest

    "Dik T. Winter" <> writes:

    > In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <> writes:
    > > "Sona" <> wrote in message
    > > news:3f71ba78$...
    > > > Could someone please explain what sign-extension means? If I have a hex
    > > > number 0x55, how does this get sign-extended? Can a sign-extended
    > > > counterpart be equal to -91? In a program I'm expecting 0x55 in return
    > > > from a function whereas I am getting -91 every time.. does this mean
    > > > anything? Thanks

    > >
    > > You can't get -91 from 0x55 in C.
    > >
    > > In a C implementation where char are signed, and twos complement, -91 would
    > > be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum of 8
    > > bits for a char.

    >
    > struct foo {
    > signed char foo: 7;
    > } foo;
    >
    > int main(void) {
    > foo.foo = 0x55;
    > printf("%d\n", foo.foo);
    > }
    >
    > But this will print -43, not -91 ;-).
    > But (signed char)(0x55 + 0x550) will do the trick if a char is 8 bits.


    ....on your implementation. Signed char in a bitfield is a
    constraint violation (§6.7.2.1#4). Other than that, converting
    0x55 (which is a positive number) to an integer type which cannot
    represent it will either yield an implementation-defined value
    (could be anything), or will raise an implementation-defined
    signal.

    -Micah
    Micah Cowan, Sep 25, 2003
    #6
  7. "Micah Cowan" <> wrote in message
    news:...
    > "Dik T. Winter" <> writes:
    > > In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt"

    <> writes:
    > > > "Sona" <> wrote in message
    > > > news:3f71ba78$...
    > > > > Could someone please explain what sign-extension means? If I have a

    hex
    > > > > number 0x55, how does this get sign-extended? Can a sign-extended
    > > > > counterpart be equal to -91? In a program I'm expecting 0x55 in

    return
    > > > > from a function whereas I am getting -91 every time.. does this

    mean
    > > > > anything? Thanks
    > > >
    > > > You can't get -91 from 0x55 in C.
    > > >
    > > > In a C implementation where char are signed, and twos complement, -91

    would
    > > > be 0xA5 in 8 bits, or 0xFFFFFFA5 in 32 bits. C requires a minimum

    of 8
    > > > bits for a char.

    > >
    > > struct foo {
    > > signed char foo: 7;
    > > } foo;
    > >
    > > int main(void) {
    > > foo.foo = 0x55;
    > > printf("%d\n", foo.foo);
    > > }
    > >
    > > But this will print -43, not -91 ;-).
    > > But (signed char)(0x55 + 0x550) will do the trick if a char is 8 bits.

    >
    > ...on your implementation. Signed char in a bitfield is a
    > constraint violation (§6.7.2.1#4).


    It presumably doesn't voilate the constraint on that implementation.

    "A bit-field shall have a type that is a qualified or unqualified version
    of
    _Bool, signed int, unsigned int, or some other implementation-defined
    type."

    I don't know if this constraint exists for C90. [I don't think so, BICBW]

    --
    Peter
    Peter Nilsson, Sep 27, 2003
    #7
  8. On Wed, 24 Sep 2003 17:08:12 GMT, Thomas Matthews
    <> wrote:
    <snip>
    > Search for these programming concepts:
    > Multiple Precision Arithmetic
    > One's Compliment
    > Two's Compliment
    >

    The correct spelling of this word is "complement"; searching for that
    is more likely to find correct answers. There is also an argument that
    the apostrophe should be moved in "ones' complement" (and more
    generally in radix-minus-one complement) but that is not nearly as
    good an indicator.

    Also note that pretty much all machines/CPUs today are 2sC. It is
    useful to understand the concepts of 1sC, and also the simpler ones
    for Sign-and-Magnitude, and how some features of the C standard
    allow(ed) for them, but don't expect to encounter them in practice.

    - David.Thompson1 at worldnet.att.net
    Dave Thompson, Sep 29, 2003
    #8
  9. Sona

    Micah Cowan Guest

    "Peter Nilsson" <> writes:

    > > ...on your implementation. Signed char in a bitfield is a
    > > constraint violation (§6.7.2.1#4).

    >
    > It presumably doesn't voilate the constraint on that implementation.
    >
    > "A bit-field shall have a type that is a qualified or unqualified version
    > of
    > _Bool, signed int, unsigned int, or some other implementation-defined
    > type."


    I read this to mean the other *type* must be an
    implementation-defined type (ruling out signed char). Is that wrong?

    > I don't know if this constraint exists for C90. [I don't think so, BICBW]


    According to my draft copy, it exists in a more strict form:
    implementation-defined types are not excepted.

    C89 §3.5.2.1 (don't have a para number):

    A bit-field may have type int, unsigned int, or signed int.
    Whether the high-order bit position of a ``plain'' int bit-field is
    treated as a sign bit is implementation-defined. A bit-field is
    interpreted as an integral type consisting of the specified number of
    bits.

    If his implementation is being invoked in ISO-conformance mode,
    then he should be getting a diagnostic.

    -Micah
    Micah Cowan, Oct 1, 2003
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave

    Supressing sign extension

    Dave, Oct 9, 2004, in forum: C++
    Replies:
    4
    Views:
    679
    Alf P. Steinbach
    Oct 10, 2004
  2. kclo4

    Sign extension

    kclo4, Nov 21, 2006, in forum: VHDL
    Replies:
    11
    Views:
    36,297
    sabgg
    May 18, 2011
  3. Jimmy
    Replies:
    1
    Views:
    902
    Cowboy \(Gregory A. Beamer\)
    Nov 21, 2006
  4. Mark
    Replies:
    13
    Views:
    3,332
    Jim Lewis
    Dec 5, 2012
  5. Jimmy
    Replies:
    3
    Views:
    2,367
    shimmyshack
    Nov 20, 2006
Loading...

Share This Page