Anyone else programming with Microchip C30? (Bitwise operation)

[Art]

Hi Guys,

I’ve been porting my reusable code to C30 from BASIC/assembler with mixed results where speed is concerned.
Bitwise operation has always been clumsy in C. Below are two examples, one in asm, and one C,
that both rotate a ten byte array bitwise one place to the right.
Does anyone have a faster (not smaller) way in C?

There could be other areas I need to check such as LCD timings, etc.
dsPic is much faster, and I thought speed difference of the code would be compensated for by that.
Cheers, Art.

RotateRight ;bitwise rotate array
rrf HMK+0 ,F ;a faster way
rrf HMK+1 ,F ;
rrf HMK+2 ,F ;
rrf HMK+3 ,F ;
rrf HMK+4 ,F ;
rrf HMK+5 ,F ;
rrf HMK+6 ,F ;
rrf HMK+7 ,F ;
rrf HMK+8 ,F ;
rrf HMK+9 ,F ;
bcf HMK+0 ,7 ;preclear MSB
btfsc status ,C ;check carry bit
bsf HMK+0 ,7 ;set MSB
return ;or return

void rotateRight() {
temp = (HMK[9] << 7); // rotate HMK right once
HMK[9] = (HMK[8] << 7) | (HMK[9] >> 1);
HMK[8] = (HMK[7] << 7) | (HMK[8] >> 1);
HMK[7] = (HMK[6] << 7) | (HMK[7] >> 1);
HMK[6] = (HMK[5] << 7) | (HMK[6] >> 1);
HMK[5] = (HMK[4] << 7) | (HMK[5] >> 1);
HMK[4] = (HMK[3] << 7) | (HMK[4] >> 1);
HMK[3] = (HMK[2] << 7) | (HMK[3] >> 1);
HMK[2] = (HMK[1] << 7) | (HMK[2] >> 1);
HMK[1] = (HMK[0] << 7) | (HMK[1] >> 1);
HMK[0] = temp | (HMK[0] >> 1);
}

[mackrackit]

I do not have an answer for you, but I have been playing with MicroChip XC8 (free version). So far the speed and code size seem about the same for similar functions.

Compile time is much faster though. So other than cross platform abilities and add in trouble like you are having, I do not see much of a reason to switch from PBP. I know,,, the dsPic is the reason.
Is that the reason you are moving to "C"?

[Art]

In this case it looks like long LCD delays were the holdup which I didn’t notice until I tried graphics.
The compiled asm for the C above would be at least 3 times slower, and probably even worse,
but the speed of the dsPic more than compensates for that without any inline asm in the C code.

The reason I chose dsPic for the particular project was floating point math,
and the fact that I’d already ported the exact functions I wanted into the exact same dsPic a few years ago,
but that was a modification to someone else’s project rather than writing a chip myself.
I understand the trig PBP library exists, but that doesn’t make it the right tool for the particular job.

I wouldn’t call it a move, I have C projects in the App Store, etc. and used Borland C for Windows,
but I have made an effort to port just about everything I might reuse because I will want the dsPic to continue to be an option.
this routine above is for character LCD graphics, it’s a 50 byte array that gets bitwise rotated often, so speed is desirable.

My current enthusiasm for it is because I have only used 16F84, 16F628, 16F876, 16F877. That’s it... ever!!
so it’s like a whole new world as far as capability is concerned, rather than about a language.

[richard]

if you made the array from longs or ints does the c compiler make better code for bit rotation ? , you could always access the array as bytes via a union . just a thought

[Art]

The array is already bytes, either declared BYTE or unsigned char.
The problem with C is aside from port pin bits or their latch registers which appear to be specially accounted for,
you still need to apply a mask to bytes to change one bit, or look/ test for a bit.
Something like asm “shift right with carry” does not seem to exist unless you went back to inline assembler in the C.
But I still think in every case the dsPic still wins because it’s running so much faster than the 20MHz/4 that I’m used to.

I’ve run into this way before now... C does suck at that.

Apologies, I wanted the picture to be interesting, but not thrown off YouTube.
You can see a large patch of the same colour because it’s a block cipher.
I had to apply a huge Xor mask to every image before hand to cover that.

[richard]

nice pic , what I was really think is , will a I bit shift on a long execute quicker than doing a 1 bit shift through 4 bytes