Hi
It seems every SHR operation (in mikropascal 7.6) results in a hex file that is 26 bytes bigger compared to a DIV operation on a pic18F .. this seems completely counter intuitive.
I really hope im wrong but as simple test like this can confirm :
var
a1,a2: Word;
begin
a1 := 2048;
a2 := a1 shr 10;
----------------------------------
compiler output: 0 1144 Used ROM (bytes): 1692 (3%) Free ROM (bytes): 63836 (97%)
----------------------------------
Now compare code generated with line
a2 := a1 div 1024;
----------------------------------
compiler output: 0 1144 Used ROM (bytes): 1666 (3%) Free ROM (bytes): 63862 (97%)
----------------------------------
Can others confirm this and share a workaround ?
Big code overhead with Bit shift operations ?
Re: Big code overhead with Bit shift operations ?
Normally, both and produce exactly the same code (10 right shifts) but in the second case compiler anticipates more complex code and, knowing a1 value, replaces the statement with result calculated at compile time.
Try the following trick that prevents compile-time calculations (compiler does not analyse assembly and has to assume variables may have changed there)and you'll see the same final code as in explicit shifting.
Code: Select all
a2 := a1 shr 10;
Code: Select all
a2 := a1 div 1024;
Try the following trick that prevents compile-time calculations (compiler does not analyse assembly and has to assume variables may have changed there)
Code: Select all
a1 := 2048;
asm nop end;
a2 :=a1 div 1024;
Re: Big code overhead with Bit shift operations ?
Interesting, but in the interest of keeping code to a minimum of instructions, wouldn't it be worthwhile to use the RRCF instruction to rotate shift the bits and then clear the first X bits ?
X being the shift right value
X being the shift right value
Re: Big code overhead with Bit shift operations ?
Well, I didn't write the compiler so I'm not responsible for the optimization applied .
Still, while one may usually write more concise code in assembly than final code produced by high-level language, in this case compiler doesn't do too bad. Clearing bits after rotation would require another loop and that would make the code longer and slower.
Still, while one may usually write more concise code in assembly than final code produced by high-level language, in this case compiler doesn't do too bad. Clearing bits after rotation would require another loop and that would make the code longer and slower.
Re: Big code overhead with Bit shift operations ?
True
But while on the topic of optimization, i stumbled upon a microchip forum post where shifts were done with 3 instructions I believe (generated by C compilers). So there's room for improvement.
Not complaining, i love the compiler, just that i wanted to see if we could push the envelope a little, here and there
But while on the topic of optimization, i stumbled upon a microchip forum post where shifts were done with 3 instructions I believe (generated by C compilers). So there's room for improvement.
Not complaining, i love the compiler, just that i wanted to see if we could push the envelope a little, here and there
Re: Big code overhead with Bit shift operations ?
Shifting 2 bytes by any number of bits in three instructions? That's hardly possible. It's more likely that it takes 3 instructions to shift 1 bit in single byte .
On average, Microchip's C compiler produces noticeably larger code than mE's compilers for 8-bit processors.
Re: Big code overhead with Bit shift operations ?
No, not shifting 2 bytes, rotating one byte
https://www.microchip.com/forums/m1141901.aspx
https://www.microchip.com/forums/m1141901.aspx