Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: Faster integer division with KEIL

2005-12-13 by brendanmurphy37

Hi,

First question I'd ask is what are you trying to do? 

To get more "bang per buck", I'd be inclined to follow the following 
strategy:

1. Re-work whatever algorithm you're using, or use a completely 
different one. Check out sources of numerical algorithms and DSP 
forums etc. for some ideas here.

2. As others have suggested, try and use special characteristics of 
the numbers you're using to optimise. Apart from the obvious (shift 
for divide by factors of two), there's limited scope here though. 
There might be scope for using look-up tables of pre-computed 
results, though.

3. Look for some good assembler functions if the built-in compiler's 
implementations aren't up to scratch.

In general, (fixed-point) division is a lot slower than 
multipication. Because of this, most algorithm work that's out there 
tends to avoid it. 

Changing algorithm (if possible) to minimise divisions will almost 
certainly give you the best results.

Brendan

--- In lpc2000@yahoogroups.com, "uedogan" <uedogan@g...> wrote:
>
> Hi everybody,
> 
> i'm currently working with the LPC2136 and the latest KEIL C-
compiler. 
> Does anybody know some functions that provide a (much) faster 16-
bit 
> unsigned integer division than KEIL currently has? I have ~58MHz 
and 
> the division currently needs about 2us.
> I would even prefer some 32-Bit unsigned integer divisions but 
these 
> run totaly out of my available timing (KEIL needs ~3.9us for that).
> 
> Does anybody know about specialised unsigned integer division 
> functions, e.g. 24bit/16bit or 16bit/8bit?
> 
> Unfortunately i'm not familiar with the ARM assembler code. So if 
> anyone can provide code then it would be helpful if it can be 
simply 
> implemented with the KEIL compiler.
> 
> Thanks a lot,
> Uenal
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.