CC65 bit shifting bug?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
-Basti-
Posts: 40
Joined: Sun Sep 26, 2010 10:29 pm

CC65 bit shifting bug?

Post by -Basti- »

Hi,
I am wondering if I am facing a known CC65 bug: I am using a simple macro to calculate, in which 32x30 tile the given x/y coordinates a placed.
The calculation is as follows: (((y/8)*32)+(x/8)). To calculate this more efficiently, I am transforming this formula, using bit operators like follows:
  • step 0: (((y/8)*32)+(x/8)) --> working
    step 1: (((y/8)*32)|(x>>3)) --> working
    step 2: (((y>>3)*32)|(x>>3)) --> working
    step 3: (((y>>3)<<5)|(x>>3)) --> working
    step 4: ((y<<2)|(x>>3)) --> not working!
I rebuild each version using Java and here all versions produce the same result. Here is the Java code:

Code: Select all

	
                int x = 110;
		int y = 50;
		
		int result1 = (((y/8)*32)+(x/8));
		int result2 = (((y>>3)<<5)|(x>>3));
		int result3 = ((y<<2)|(x>>3));
		
		System.out.println(result1); //output: 205
		System.out.println(result2); //output: 205
		System.out.println(result3); //output: 205
I guess there is something special with CC65 bit shifting? The problem obviously lies in the part when combining two shifts into one.

Regards
Sebastian
russellsprouts
Posts: 53
Joined: Sun Jan 31, 2016 9:55 pm

Re: CC65 bit shifting bug?

Post by russellsprouts »

step 3: (((y>>3)<<5)|(x>>3)) --> working
step 4: ((y<<2)|(x>>3)) --> not working!
This isn't a valid transformation. ((y>>3)<<5) is not equivalent to (y<<2). If it were, then (y>>3)<<3 would be the same as y, but when you do y>>3, you chop off the lower 3 bits, and doing y<<3 afterward doesn't bring them back.
User avatar
-Basti-
Posts: 40
Joined: Sun Sep 26, 2010 10:29 pm

Re: CC65 bit shifting bug?

Post by -Basti- »

Thanks for explaining. I guess this operation is working in my Java code, since I use int and not unsigned char, like in my C code.
russellsprouts
Posts: 53
Joined: Sun Jan 31, 2016 9:55 pm

Re: CC65 bit shifting bug?

Post by russellsprouts »

You are right that int and unsigned char will have different behaviors. In Java, >> is an arithmetic right shift, while for an unsigned number you will get a logical right shift (in Java represented by >>>).

You are working to optimize this part of the expression:
((y>>3)<<5).

This might be compiled something like:

Code: Select all

lda yValue
lsr
lsr
lsr
asl
asl
asl
asl
asl
Note that doing shifts by amounts more than 1 takes multiple instructions on the 6502, so replacing it with a different operation can be beneficial.

If you have a byte y made up of bits a-h:
abcdefgh

y>>3 is:
000abcde

and that shifted left 5 is:
cde00000

So the value is equivalent to:
(y<<2)&0b11100000

This can be compiled to

Code: Select all

lda yValue
asl
asl
and #%11100000
Post Reply