sdcc version: 3.4.0 #8981 (May 19 2014) (Linux)
(given by sdcc --version)
I use the timer 1 of the device to measure the execution time. It has a 16-bits counter. Configure it for increment at frequency Fosc/4, which is the same frequency instructions are executed.
Template implementations of the mul, div, shift operations are in attached file.
Obtained execution times are in comments.
Sorry these are French ones but should be transparent enough. Ask if somethin's not clear.
It probably needs more extensive testing than what I can do with my chip.
Some cases are (intentionally) not covered for shifts because there can be discussion about how to handle best: shift value 16 for 16-bits data, shift value 8 for 8-bits data.
Overall, the proposed implementations are either faster in all cases, or notably faster for worst-case scenarios and only a bit slower for best-case situations.
It is probably possible to improve more. Especially if done at asm level.
All this is only a suggestion, open to any modification/correction/improvement.
Argh, I sent a slightly older .c file, there was an error in div functions:
add this "div >>= 1;" in the second loop of the functions, just beside "d >>= 1;"
The speedup is a bit smaller but it is still there.
Update: I added even more speed optimizations with smaller code.
This is for unsigned division, multiplication, shifts.
And a few fixes for multiplication, compared to previous attached file.
See attached file.
Comments are now English.
More test results are given in comments (in number of instructions as measured with the timer 1 of device 16F684).
Compared to builtin sdcc libs, this often brings 40% speed increase, sometimes higher, sometimes less.
For shifts, 2 implementations are proposed, that could be chosen with sdcc parameter to optim for speed or size.
Ticket moved from /p/sdcc/bugs/2325/
Can't be converted:
A feature request, not a bug.
Philipp