Velocity Reviews > Sign-extension?

# Sign-extension?

Sona
Guest
Posts: n/a

 09-24-2003
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

Thomas Stegen
Guest
Posts: n/a

 09-24-2003

"Sona" <(E-Mail Removed)> wrote in message
news:3f71ba78\$(E-Mail Removed)...
> 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 Matthews
Guest
Posts: n/a

 09-24-2003
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

Glen Herrmannsfeldt
Guest
Posts: n/a

 09-24-2003

"Sona" <(E-Mail Removed)> wrote in message
news:3f71ba78\$(E-Mail Removed)...
> 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

Dik T. Winter
Guest
Posts: n/a

 09-25-2003
In article <Hwpcb.573738\$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <(E-Mail Removed)> writes:
> "Sona" <(E-Mail Removed)> wrote in message
> news:3f71ba78\$(E-Mail Removed)...
> > 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/

Micah Cowan
Guest
Posts: n/a

 09-25-2003
"Dik T. Winter" <(E-Mail Removed)> writes:

> In article <Hwpcb.573738\$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <(E-Mail Removed)> writes:
> > "Sona" <(E-Mail Removed)> wrote in message
> > news:3f71ba78\$(E-Mail Removed)...
> > > 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

Peter Nilsson
Guest
Posts: n/a

 09-27-2003
"Micah Cowan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Dik T. Winter" <(E-Mail Removed)> writes:
> > In article <Hwpcb.573738\$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt"

<(E-Mail Removed)> writes:
> > > "Sona" <(E-Mail Removed)> wrote in message
> > > news:3f71ba78\$(E-Mail Removed)...
> > > > 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

Dave Thompson
Guest
Posts: n/a

 09-29-2003
On Wed, 24 Sep 2003 17:08:12 GMT, Thomas Matthews
<(E-Mail Removed)> 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

Micah Cowan
Guest
Posts: n/a

 09-30-2003
"Peter Nilsson" <(E-Mail Removed)> 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