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.