Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > bitshift operator problem

Reply
Thread Tools

bitshift operator problem

 
 
Serve Laurijssen
Guest
Posts: n/a
 
      09-05-2008
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?

 
Reply With Quote
 
 
 
 
Serve Laurijssen
Guest
Posts: n/a
 
      09-05-2008

"Eric Sosman" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> 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.

 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      09-05-2008
Serve Laurijssen wrote, On 05/09/08 14:56:
>
> "Eric Sosman" <(E-Mail Removed)> schreef in bericht
> news:(E-Mail Removed)...
>> 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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-05-2008
"Serve Laurijssen" <(E-Mail Removed)> writes:
> "Eric Sosman" <(E-Mail Removed)> schreef in bericht
> news:(E-Mail Removed)...
>> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Serve Laurijssen
Guest
Posts: n/a
 
      09-05-2008

"Flash Gordon" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)-gordon.me.uk...
> 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.


> 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

 
Reply With Quote
 
Willem
Guest
Posts: n/a
 
      09-05-2008
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
 
Reply With Quote
 
Ali Karaali
Guest
Posts: n/a
 
      09-06-2008
Alright ;

What happenes if a sign integer shifts left or right?

I mean what is the situation of sign bit.
 
Reply With Quote
 
Ali Karaali
Guest
Posts: n/a
 
      09-06-2008
> *If E1 has a signed type and nonnegative value,
> * * * * and E12E2 is representable in the result type, then that is
> * * * * the resulting value; OTHERWISE, the behavior is undefined..



What is OTHERWISE?
 
Reply With Quote
 
Ali Karaali
Guest
Posts: n/a
 
      09-06-2008
> * * *If `1' is negative (that is, if the left-hand operand, not
> actually `1', is negative), the behavior is undefined.
>
> --
> Eric Sosman
> (E-Mail Removed)


Actually I would like to know what is the result of?
Was it define?

int i = 1; // i is a signed integer
i << 2;
 
Reply With Quote
 
Ali Karaali
Guest
Posts: n/a
 
      09-06-2008
> Eric Sosman
> (E-Mail Removed)


What about;

signed char i = 1;

i << 7;

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
bitshift Bill Cunningham C Programming 1 11-09-2011 12:01 AM
trouble converting c++ bitshift to python equivalent nanodust@gmail.com Python 6 05-24-2007 09:01 PM
bitshift a large amount of data Eric.Medlin@gmail.com C++ 8 02-10-2006 12:06 AM
What's the point of bitshift? Ryan Java 4 02-14-2005 03:01 AM
Using bitshift in assigning a number to a variable? bollod C Programming 12 12-27-2003 05:45 PM



Advertisments