«

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" <> schreef in bericht
news:McOdnWqfr-...
> 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.

Serve Laurijssen wrote, On 05/09/08 14:56:
>
> "Eric Sosman" <> schreef in bericht
> news:McOdnWqfr-...
>> 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

"Serve Laurijssen" <> writes:
> "Eric Sosman" <> schreef in bericht
> news:McOdnWqfr-...
>> 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- <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"

"Flash Gordon" <> schreef in bericht
news:...
> 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

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

Alright ;

What happenes if a sign integer shifts left or right?

I mean what is the situation of sign bit.

> *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..


What is OTHERWISE?

> * * *If `1' is negative (that is, if the left-hand operand, not
> actually `1', is negative), the behavior is undefined.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

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

int i = 1; // i is a signed integer
i << 2;

> Eric Sosman
> esos...@ieee-dot-org.invalid

What about;

signed char i = 1;

i << 7;