I stand corrected: the "smull" instruction does indeed produce a 64-
bit result.
The LPC2000 series parts definitely do have the DSP extensions: we
use them in some of our signal processing software. I believe the "M"
in ARM7TDMI indicates this (I could be wrong on this).
Using saturated math can get quite messy: apart from the fact that
compilers generally don't support them well (if at all), you have to
be very careful about downstream effects if the result is fed into
further calculations.
I'd still be inclined to work at 16-bit values with 32-bit results,
as some operations on 64-bit values can be quite slow. I'm making the
assumption here that speed is of the essence: if not, there's no
problem with just getting the compiler and processor to get on with
it. Having said that, we've just completed a very acurate phase
measurement system using a LPC2134 that uses 64-bit intermediate
results, so I'm not really following my own advice.
Brendan
--- In lpc2000@yahoogroups.com, "Aalt Lokhorst" <lokhorst@s...> wrote:
> 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@S...
> ==============================
>
> 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: How to detect a multiply overflow?
2005-08-10 by brendanmurphy37