464,315 Members | 1,268 Online
Need help? Post your question and get tips & solutions from a community of 464,315 IT Pros & Developers. It's quick & easy.

# Sign-extension?

 P: n/a 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 Nov 13 '05 #1
10 Replies

 P: n/a "Sona" wrote in message news:3f********@clarion.carno.net.au... 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. Nov 13 '05 #2

 P: n/a 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 Nov 13 '05 #3

 P: n/a "Sona" wrote in message news:3f********@clarion.carno.net.au... 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. Nov 13 '05 #4

 P: n/a 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 Nov 13 '05 #5

 P: n/a "Sona" wrote in message news:3f********@clarion.carno.net.au... 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 Nov 13 '05 #6

 P: n/a In article "Glen Herrmannsfeldt" writes: "Sona" wrote in message news:3f********@clarion.carno.net.au... 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/ Nov 13 '05 #7

 P: n/a "Dik T. Winter" writes: In article "Glen Herrmannsfeldt" writes: > "Sona" wrote in message > news:3f********@clarion.carno.net.au... > > 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 Nov 13 '05 #8

 P: n/a "Micah Cowan" wrote in message news:m3************@localhost.localdomain... "Dik T. Winter" writes: In article "Glen Herrmannsfeldt" writes: > "Sona" wrote in message > news:3f********@clarion.carno.net.au... > > 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 Nov 13 '05 #9

 P: n/a On Wed, 24 Sep 2003 17:08:12 GMT, Thomas Matthews wrote: 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 Nov 13 '05 #10

 P: n/a "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 Nov 13 '05 #11

### This discussion thread is closed

Replies have been disabled for this discussion.