Sign-extension?

[Sona]

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]

"Sona" <so**********@nospam.com> 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.

[Thomas Matthews]

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 Stegen]

"Sona" <so**********@nospam.com> 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.

[Thomas Matthews]

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]

"Sona" <so**********@nospam.com> 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

[Dik T. Winter]

In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

"Sona" <so**********@nospam.com> 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, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Micah Cowan]

"Dik T. Winter" <Di********@cwi.nl> writes:

In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

> "Sona" <so**********@nospam.com> 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

[Peter Nilsson]

"Micah Cowan" <mi***@cowan.name> wrote in message
news:m3************@localhost.localdomain...

"Dik T. Winter" <Di********@cwi.nl> writes:

In article <Hwpcb.573738$uu5.94114@sccrnsc04> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

> "Sona" <so**********@nospam.com> 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

[Dave Thompson]

On Wed, 24 Sep 2003 17:08:12 GMT, Thomas Matthews
<Th**********************@sbcglobal.net> 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]

"Peter Nilsson" <ai***@acay.com.au> 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