Thanks for your answers,
I have tried the solution of Anton and I think this will do the job.
(See also the resulting assembler code further in this email)
At first I was thinking about a function which should estimate the
number of result-bits needed. (By adding the number of bits needed for
each variable without counting the leading zero's) This would be only a
rough estimation, see this example for two 3-bit values:
100b * 100b = 10000b (result 5 bit)
111b * 111b = 110001b (result 6 bit)
Adding the number of bits of both variables results in the worst case
situation. This is not ideal because there are situations which need a
bit less than the estimation shows I don't even mention the issues
involved with negative numbers.
Even if my 'solution' would work after solving all the issues then it
will be slow compared to a multiply with 64 bit result (and saturating
the result to 32 bit)
Brendan Murphy wrote:
>> However, for 32-bit arguments this is
>> likely to be slow, as there's no native processing of 64-bit values:
>> the compiler will call an internal library function to do the math.
A small test shows the following:
void test (void)
{
int32_t A, B;
int64_t C;
A = 0x12345678;
B = 0x11223344;
C = (int64_t)A * (int64_t)B;
}
Results in: (code for entering and leaving the function is stripped)
A = 0x12345678;
E59F3038 ldr r3, [pc, #56] ;R3 = 0x12345678
E50B301C str r3, [r11, #-28] ;write R3 to stack
B = 0x11223344;
E59F3034 ldr r3, [pc, #52] ;R3 = 0x11223344
E50B3020 str r3, [r11, #-32] ;write R3 to stack
C = (int64_t)A * (int64_t)B;
E3E0300F mvn r3, #0x0000000F ;some calculation of
E24B2018 sub r2, r11, #0x00000018 ;stack address for
E0821003 add r1, r2, r3 ;the mul result
E51B201C ldr r2, [r11, #-28] ;get value 'A' in R2
E51B3020 ldr r3, [r11, #-32] ;get value 'B' in R3
E0C65392 smull r5, r6, r2, r3 ;multiply R2*R3 and
;put result in R5R6
E1A04006 mov r4, r6 ;R4 = Result 'High'
E1A03005 mov r3, r5 ;R3 = Result 'Low'
E8810018 stmia r1, {r3-r4} ;store result
Not a bad result I think, no library function needed.
Brendan also wrote about "Enhanced DSP instructions" for the LPC2000
series. Such instructions are perfect for my application, but are you
sure the LPC2000 does support these instructions? I think the ARM7 does
not have such instructions.
And now the final question:
Do I really need 32 bit or even 64 bit intermediate results???
Well, actually almost never. My application runs fine with smaller
numbers if the closed loop process behaves correct. But if something
went wrong with a setpoint, the process or the PID-parameters then the
error-value can increase enormous and a integrator windup might occur.
I can check for all the problematic situations but it is a lot easier if
the intermediate variables have simply enough bits to hold the 'worst
case' results, or if I could a use a 'saturate' solution.
Thanks for your help.
Aalt
--
==============================
Aalt Lokhorst
Schut Geometrische Meettechniek bv
Duinkerkenstraat 21
9723 BN Groningen
P.O. Box 5225
9700 GE Groningen
The Netherlands
Tel: +31-50-5877877
Fax: +31-50-5877899
E-mail: Lokhorst@...
==============================
brendanmurphy37 wrote:
>
> Hi,
>
> In the general case, you're pretty much guaranteed overflow:
> multiplying two numbers of a fixed precision (e.g. 16-bits) gives a
> result twice that precision (in that case 32-bits). As another reply
> has pointed out, you can simply declare the result to have twice the
> precision of the two arguments. However, for 32-bit arguments this is
> likely to be slow, as there's no native processing of 64-bit values:
> the compiler will call an internal library function to do the math.
>
> It might be worth your while looking at the "Enhanced DSP
> instructions" (see ARM documentation from ARM): these provide various
> forms of multiply and add, including some that saturate. The LPC2000
> series as ARM7TDMI devices support these instructions.
>
> A final thought that strikes me is that do you really need 32-bit
> arguments? In general 16-bit is fine for most purposes as an input
> resolution. You can still accumulate at 32- or 64-bits (scaling back
> to 16-bits if further processing is required).
>
> Hope this is of some help.
>
> Regards
> Brendan Murphy
>
> --- In lpc2000@yahoogroups.com, "Aalt Lokhorst" <lokhorst@s...> wrote:
> > Hello All,
> >
> > I have concerns about a PID routine which is doing some
> calculations
> > with 32-bit values. It uses multiply and add instructions. My
> concern
> > about this is, how to detect overflow.
> >
> > A overflow can result in a process correction with a wrong sign and
> this
> > is not acceptable for the process. What I need in a overflow
> situation
> > is a saturated value.
> >
> > In the past I was using a 8052, multiplying 32-bit values was
> possible
> > but it was done in a lot of 8-bit portions.
> > With the ARM I can do the same in one instruction but I am missing
> the
> > overflow flag. Is there a option to detect an overflow after a
> multiply?
> >
> > I am using the LPC2129 (ARM7)
> >
> > Greetings
> > Aalt
> >
> > --
> > ==============================
> > Aalt Lokhorst
> > Schut Geometrische Meettechniek bv
> > Duinkerkenstraat 21
> > 9723 BN Groningen
> > P.O. Box 5225
> > 9700 GE Groningen
> > The Netherlands
> > Tel: +31-50-5877877
> > Fax: +31-50-5877899
> > E-mail: Lokhorst@S...
> > ==============================
>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
> * Visit your group "lpc2000
> <http://groups.yahoo.com/group/lpc2000>" on the web.
>
> * To unsubscribe from this group, send an email to:
> lpc2000-unsubscribe@yahoogroups.com
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>Message
Re: [lpc2000] Re: How to detect a multiply overflow?
2005-08-10 by Aalt Lokhorst