Google
 
Webnews.only-4-geeks.com
Interesting places
news.only-4-geeks.com Forum Index » CGoto page 1, 2, 3  Next

bitshift operator problem

 
Jump to:  
 
Serve Laurijssen
PostPosted: Fri Sep 05, 2008 9:03 am    Post subject: bitshift operator problem
       
I've been working on an old 8-bit system and came across a problem with the
<< operator

This would always yield 0:

unsigned char i;
for (i = 0; i < 4; i++)
{
unsigned char idx = 1 << i;
....
}

while this worked as expected:

unsigned char i, mask = 1;
for (i = 0; i < 4; i++)
{
unsigned char idx = mask;
....
mask = mask << 1;
}

Is there something wrong with the first version considering that this is
code for an 8-bitter?
 

 
Eric Sosman
PostPosted: Fri Sep 05, 2008 9:18 am    Post subject: Re: bitshift operator problem
       
Serve Laurijssen wrote:
Quote:
I've been working on an old 8-bit system and came across a problem with
the << operator

This would always yield 0:

unsigned char i;
for (i = 0; i < 4; i++)
{
unsigned char idx = 1 << i;
....
}

By "yield 0" do you mean that the value of idx was
always zero in "...."? That shouldn't be so: idx should
have been 1, 2, 4, 8 on the four loop iterations. How
did you discover that idx was zero (or have I not
understood your complaint)?

Quote:
while this worked as expected:

unsigned char i, mask = 1;
for (i = 0; i < 4; i++)
{
unsigned char idx = mask;
....
mask = mask << 1;
}

What were your expectations, and how did you verify
that they were met? In this loop, both idx and mask should
have the values 1, 2, 4, 8 during "...." in each iteration,
and mask should be 16 after the loop ends.

Quote:
Is there something wrong with the first version considering that this is
code for an 8-bitter?

First tell us more about your intentions, and about your
means of discovering what your code fragments are doing.

--
Eric Sosman
esosman@ieee-dot-org.invalid
 

 
Serve Laurijssen
PostPosted: Fri Sep 05, 2008 11:56 am    Post subject: Re: bitshift operator problem
       
"Eric Sosman" <esosman@ieee-dot-org.invalid> schreef in bericht
news:McOdnWqfr-EYiFzVnZ2dnUVZ_g2dnZ2d@comcast.com...
Quote:
Serve Laurijssen wrote:
I've been working on an old 8-bit system and came across a problem with
the << operator

This would always yield 0:

unsigned char i;
for (i = 0; i < 4; i++)
{
unsigned char idx = 1 << i;
....
}

By "yield 0" do you mean that the value of idx was
always zero in "...."? That shouldn't be so: idx should
have been 1, 2, 4, 8 on the four loop iterations. How
did you discover that idx was zero (or have I not
understood your complaint)?

That was what I meant yes. It was seen with a debugger. I'm guessing a
compiler bug then

Quote:
First tell us more about your intentions, and about your
means of discovering what your code fragments are doing.

a debugger. The bits were used to set a signal and after that read a signal
from a register to check if a button was pressed.
 

 
Flash Gordon
PostPosted: Fri Sep 05, 2008 12:22 pm    Post subject: Re: bitshift operator problem
       
Serve Laurijssen wrote, On 05/09/08 14:56:
Quote:

"Eric Sosman" <esosman@ieee-dot-org.invalid> schreef in bericht
news:McOdnWqfr-EYiFzVnZ2dnUVZ_g2dnZ2d@comcast.com...
Serve Laurijssen wrote:
I've been working on an old 8-bit system and came across a problem
with the << operator

This would always yield 0:

unsigned char i;
for (i = 0; i < 4; i++)
{
unsigned char idx = 1 << i;
....
}

By "yield 0" do you mean that the value of idx was
always zero in "...."? That shouldn't be so: idx should
have been 1, 2, 4, 8 on the four loop iterations. How
did you discover that idx was zero (or have I not
understood your complaint)?

That was what I meant yes. It was seen with a debugger. I'm guessing a
compiler bug then

First tell us more about your intentions, and about your
means of discovering what your code fragments are doing.

a debugger. The bits were used to set a signal and after that read a
signal from a register to check if a button was pressed.

Did you use the value of idx? I'm guessing possibly not, or possibly it
was only assigned to what C thought of as a variable but was actually
memory mapped HW. Check that you have used 'volatile' for the
declaration/definition of anything which is mapped to HW.

I've implemented scanning a hex keypad in SW before, strobing the fours
lines checking for whether any of the relevant 4 bits are set, and I'm
guessing this is what you are doing. I was doing it because I was
writing SW to test the keypad, normally I would just use a dedicated
chip to do it.
--
Flash Gordon
 

 
Keith Thompson
PostPosted: Fri Sep 05, 2008 1:20 pm    Post subject: Re: bitshift operator problem
       
"Serve Laurijssen" <zhu@woaini.com> writes:
Quote:
"Eric Sosman" <esosman@ieee-dot-org.invalid> schreef in bericht
news:McOdnWqfr-EYiFzVnZ2dnUVZ_g2dnZ2d@comcast.com...
Serve Laurijssen wrote:
I've been working on an old 8-bit system and came across a problem
with the << operator

This would always yield 0:

unsigned char i;
for (i = 0; i < 4; i++)
{
unsigned char idx = 1 << i;
....
}

By "yield 0" do you mean that the value of idx was
always zero in "...."? That shouldn't be so: idx should
have been 1, 2, 4, 8 on the four loop iterations. How
did you discover that idx was zero (or have I not
understood your complaint)?

That was what I meant yes. It was seen with a debugger. I'm guessing a
compiler bug then

Or a debugger bug.

[...]

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 

 
Eric Sosman
PostPosted: Fri Sep 05, 2008 3:03 pm    Post subject: Re: bitshift operator problem
       
Serve Laurijssen wrote:
Quote:

"Eric Sosman" <esosman@ieee-dot-org.invalid> schreef in bericht
news:McOdnWqfr-EYiFzVnZ2dnUVZ_g2dnZ2d@comcast.com...
Serve Laurijssen wrote:
I've been working on an old 8-bit system and came across a problem
with the << operator

This would always yield 0:

unsigned char i;
for (i = 0; i < 4; i++)
{
unsigned char idx = 1 << i;
....
}

By "yield 0" do you mean that the value of idx was
always zero in "...."? That shouldn't be so: idx should
have been 1, 2, 4, 8 on the four loop iterations. How
did you discover that idx was zero (or have I not
understood your complaint)?

That was what I meant yes. It was seen with a debugger. I'm guessing a
compiler bug then

Compilers certainly have bugs, but a bug as basic as this
would very likely have been detected and fixed long ago. It
seems to me more likely that you're looking in the wrong place.
Keep in mind that when you assign a value to idx, the compiler is
not obliged to store that value in idx' memory cell immediately.
It might, for example, hold the value in a CPU register until
several assignments have been made, and only store the last of
them. It might even eliminate all stores, if it can deduce
that they're not needed. Compilers are sly, devious beasts
at times.

From a C language perspective, all we can say is that
`idx = 1 << i;' is perfectly valid, and should yield a well-
defined result (for the types and values in your code). The
particulars of what your compiler does with the code and/or
how your debugger observes the result are specific to your
compiler and debugger. Another forum -- comp.arch.embedded,
maybe? -- might be of help with those matters.

--
Eric Sosman
esosman@ieee-dot-org.invalid
 

 
Serve Laurijssen
PostPosted: Fri Sep 05, 2008 5:20 pm    Post subject: Re: bitshift operator problem
       
"Flash Gordon" <spam@flash-gordon.me.uk> schreef in bericht
news:2ur7p5x7q4.ln2@news.flash-gordon.me.uk...
Quote:
Did you use the value of idx? I'm guessing possibly not, or possibly it
was only assigned to what C thought of as a variable but was actually
memory mapped HW. Check that you have used 'volatile' for the
declaration/definition of anything which is mapped to HW.

Ok thanks. I just wanted to know if (1<<i) was 100% correct from a C point
of view. The expression would be converted to int because of the 1 which
caused the problem. Using ints on this platform generates lots more (non
atomic) instructions and since it was called in an interrupt handler some
stuff could go wrong there. But anyway, ((unsigned char)1<<i) didnt work
either.


Quote:
I've implemented scanning a hex keypad in SW before, strobing the fours
lines checking for whether any of the relevant 4 bits are set, and I'm
guessing this is what you are doing. I was doing it because I was writing
SW to test the keypad, normally I would just use a dedicated chip to do
it.

it was just part of a test program
 

 
Willem
PostPosted: Fri Sep 05, 2008 8:03 pm    Post subject: Re: bitshift operator problem
       
Serve Laurijssen wrote:
) Ok thanks. I just wanted to know if (1<<i) was 100% correct from a C point
) of view. The expression would be converted to int because of the 1 which
) caused the problem. Using ints on this platform generates lots more (non
) atomic) instructions and since it was called in an interrupt handler some
) stuff could go wrong there. But anyway, ((unsigned char)1<<i) didnt work
) either.

Maybe you should check what the assembler instructions are that the
compiler generates.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 

 
pete
PostPosted: Fri Sep 05, 2008 10:18 pm    Post subject: Re: bitshift operator problem
       
Ali Karaali wrote:
Quote:
Alright ;

What happenes if a sign integer shifts left or right?

I mean what is the situation of sign bit.

N869
6.5.7 Bitwise shift operators

[#4] The result of E1 << E2 is E1 left-shifted E2 bit
positions; vacated bits are filled with zeros. If E1 has an
unsigned type, the value of the result is E1×2E2, reduced
modulo one more than the maximum value representable in the
result type. If E1 has a signed type and nonnegative value,
and E1×2E2 is representable in the result type, then that is
the resulting value; otherwise, the behavior is undefined.

[#5] The result of E1 >> E2 is E1 right-shifted E2 bit
positions. If E1 has an unsigned type or if E1 has a signed
type and a nonnegative value, the value of the result is the
integral part of the quotient of E1 divided by the quantity,
2 raised to the power E2. If E1 has a signed type and a
negative value, the resulting value is implementation-
defined.

--
pete
 

 
Eric Sosman
PostPosted: Fri Sep 05, 2008 11:00 pm    Post subject: Re: bitshift operator problem
       
Ali Karaali wrote:

[... without quoting any context to make his message sensible.
For those just tuning in, the question was about `1 << i'.]

Quote:
Alright ;

What happenes if a sign integer shifts left or right?

I mean what is the situation of sign bit.

It's not clear whether you're asking about the signedness
of `i' or of `1' (which is obviously positive, but perhaps you
are asking about a more general left-hand operand).

If `i' is negative, the behavior is undefined. Note that
this is a weaker statement than "the result is undefined,"
because it does not even imply that there will be a result.
Similarly, the behavior is undefined if `i' is greater than
*or equal to* the number of value bits in the (promoted) left-
hand operand, or if `i' is large enough to cause any one-bit
of the l.h.o. to be shifted beyond the value-bit positions.

If `1' is negative (that is, if the left-hand operand, not
actually `1', is negative), the behavior is undefined.

--
Eric Sosman
esosman@ieee-dot-org.invalid
 

Page 1 of 3 .:. Goto page 1, 2, 3  Next

Google
 
Webnews.only-4-geeks.com

Windows Update | C++ | C | PHP | JavaScript | Photoshop | Programming | Windows 2000 | Python | Windows XP | Object | Flash | Flash - ActionScript | Paint Shop Pro | Excel | PowerPoint | Access | Word | Windows 98 | Internet Explorer 6.0 | CorelDraw12 | Java | XML | asm x86 | Linux Mandrake | Linux RedHat | Outlook |  | news from newsgroups |_ | s

Web Templates

Awesome Website Templates ©

Srebrne monety najtańsze ubezpieczenie poker online Socken Herstellung hale namiotowe