Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #7760 > unrolled thread

Floating point vs fixed arithmetics (signed 64-bit)

Back to article view | Back to comp.arch.embedded

Contents

  Floating point vs fixed arithmetics (signed 64-bit) kishor <kiishor@gmail.com> - 2012-03-26 02:22 -0700
    Re: Floating point vs fixed arithmetics (signed 64-bit) "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2012-03-26 12:08 +0200
    Re: Floating point vs fixed arithmetics (signed 64-bit) Arlet Ottens <usenet+5@c-scape.nl> - 2012-03-26 13:14 +0200
      Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-26 13:24 +0200
        Re: Floating point vs fixed arithmetics (signed 64-bit) kishor <kiishor@gmail.com> - 2012-03-26 05:24 -0700
          Re: Floating point vs fixed arithmetics (signed 64-bit) Fredrik Östman <Fredrik_Oestman@work.invalid> - 2012-03-26 12:38 +0000
            Re: Floating point vs fixed arithmetics (signed 64-bit) kishor <kiishor@gmail.com> - 2012-03-26 06:33 -0700
              Re: Floating point vs fixed arithmetics (signed 64-bit) Arlet Ottens <usenet+5@c-scape.nl> - 2012-03-26 15:49 +0200
              Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-26 15:45 +0200
              Re: Floating point vs fixed arithmetics (signed 64-bit) Fredrik Östman <Fredrik_Oestman@work.invalid> - 2012-03-26 14:34 +0000
          Re: Floating point vs fixed arithmetics (signed 64-bit) Arlet Ottens <usenet+5@c-scape.nl> - 2012-03-26 15:34 +0200
            Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.com> - 2012-03-26 12:25 -0500
              Re: Floating point vs fixed arithmetics (signed 64-bit) Arlet Ottens <usenet+5@c-scape.nl> - 2012-03-26 20:19 +0200
                Re: Floating point vs fixed arithmetics (signed 64-bit) Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-03-26 16:45 -0400
                  Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.com> - 2012-03-26 17:15 -0500
                    Re: Floating point vs fixed arithmetics (signed 64-bit) Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-03-26 19:09 -0400
                      Re: Floating point vs fixed arithmetics (signed 64-bit) kishor <kiishor@gmail.com> - 2012-03-27 04:59 -0700
                        Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-27 15:25 +0200
                          Re: Floating point vs fixed arithmetics (signed 64-bit) David T. Ashley <dashley@gmail.com> - 2012-03-29 13:17 -0400
    Re: Floating point vs fixed arithmetics (signed 64-bit) "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-03-27 11:28 +0100
    Re: Floating point vs fixed arithmetics (signed 64-bit) David T. Ashley <dashley@gmail.com> - 2012-03-27 11:28 -0400
      Re: Floating point vs fixed arithmetics (signed 64-bit) upsidedown@downunder.com - 2012-03-27 18:52 +0300
        Re: Floating point vs fixed arithmetics (signed 64-bit) David T. Ashley <dashley@gmail.com> - 2012-03-27 13:02 -0400
          Re: Floating point vs fixed arithmetics (signed 64-bit) Walter Banks <walter@bytecraft.com> - 2012-03-27 13:56 -0500
            Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.com> - 2012-03-27 14:17 -0500
              Re: Floating point vs fixed arithmetics (signed 64-bit) Walter Banks <walter@bytecraft.com> - 2012-03-27 15:35 -0500
                Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.please> - 2012-03-27 22:36 -0500
            Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-28 09:00 +0200
            Re: Floating point vs fixed arithmetics (signed 64-bit) j.m.granville@gmail.com - 2012-03-30 04:08 -0700
              Re: Floating point vs fixed arithmetics (signed 64-bit) Mark Borgerson <mborgerson@comcast.net> - 2012-04-02 22:52 -0700
                Re: Floating point vs fixed arithmetics (signed 64-bit) John Devereux <john@devereux.me.uk> - 2012-04-03 11:33 +0100
                  Re: Floating point vs fixed arithmetics (signed 64-bit) Anders.Montonen@kapsi.spam.stop.fi.invalid - 2012-04-03 12:05 +0000
                    Re: Floating point vs fixed arithmetics (signed 64-bit) John Devereux <john@devereux.me.uk> - 2012-04-03 16:34 +0100
                      Re: Floating point vs fixed arithmetics (signed 64-bit) Paul <paul@pcserviceselectronics.co.uk> - 2012-04-04 09:35 +0100
              Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.com> - 2012-04-03 13:52 -0500
                Re: Floating point vs fixed arithmetics (signed 64-bit) Mark Borgerson <mborgerson@comcast.net> - 2012-04-04 16:50 -0700
                  Re: Floating point vs fixed arithmetics (signed 64-bit) John Devereux <john@devereux.me.uk> - 2012-04-05 11:48 +0100
          Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-28 09:17 +0200
            Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.com> - 2012-03-28 12:20 -0500
              Re: Floating point vs fixed arithmetics (signed 64-bit) Andrew Reilly <areilly---@bigpond.net.au> - 2012-03-28 22:44 +0000
                Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.com> - 2012-03-28 18:35 -0500
                  Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-29 10:58 +0200
                  Re: Floating point vs fixed arithmetics (signed 64-bit) Mark Borgerson <mborgerson@comcast.net> - 2012-03-29 07:56 -0700
                    Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.com> - 2012-03-29 16:52 -0500
                      Re: Floating point vs fixed arithmetics (signed 64-bit) Mark Borgerson <mborgerson@comcast.net> - 2012-03-29 21:19 -0700
                        Re: Floating point vs fixed arithmetics (signed 64-bit) Tim Wescott <tim@seemywebsite.please> - 2012-03-30 00:42 -0500
                Re: Floating point vs fixed arithmetics (signed 64-bit) upsidedown@downunder.com - 2012-03-29 07:19 +0300
                  Re: Floating point vs fixed arithmetics (signed 64-bit) Andrew Reilly <areilly---@bigpond.net.au> - 2012-03-29 11:53 +0000
                    Re: Floating point vs fixed arithmetics (signed 64-bit) Walter Banks <walter@bytecraft.com> - 2012-03-29 09:40 -0500
                    Re: Floating point vs fixed arithmetics (signed 64-bit) upsidedown@downunder.com - 2012-03-29 23:46 +0300
                  Re: Floating point vs fixed arithmetics (signed 64-bit) Walter Banks <walter@bytecraft.com> - 2012-03-29 09:28 -0500
                    Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-29 16:58 +0200
              Re: Floating point vs fixed arithmetics (signed 64-bit) David Brown <david@westcontrol.removethisbit.com> - 2012-03-29 10:09 +0200
              Re: Floating point vs fixed arithmetics (signed 64-bit) Clifford Heath <cjh@no.spam.please.net> - 2012-04-01 18:08 +1000
            Re: Floating point vs fixed arithmetics (signed 64-bit) dp <dp@tgi-sci.com> - 2012-03-28 02:38 -0700
        Re: Floating point vs fixed arithmetics (signed 64-bit) upsidedown@downunder.com - 2012-03-28 22:59 +0300

Page 1 of 3  [1] 2 3  Next page →

#7760 — Floating point vs fixed arithmetics (signed 64-bit)

	Hi friends,
	I am working on stellaris LM3s6965 (cortex-m3) & Keil 4.20 for data
acquisition. ADC
	is signed 24-bit.

	To perform software Gain calibration I have two options,

	1. 64-bit fixed width arithmetic
		uint16_t Gain;		// 0x8000 means gain is 1
		int32_t ADC_Reading;		// It contains 24-bit signed integer ADC
reading

		ADC_Reading = ((int64_t)ADC_Reading * Gain) / 0x8000;           //
Gain calibration

		// As multiplication of signed 24-bit & unsigned 16-bit will not fit
into 32-bit variable
		// I typecast it to int64_t.

	2. Single precision Float
		float Gain;
		int32_t ADC_Reading;		// It contains 24-bit signed integer ADC
reading

		ADC_Reading = ADC_Reading * Gain;                     // Gain
calibration

		Which is better for performance wise.

		Thanks,
		Kishore.

[toc] | [next] | [standalone]

#7762

Op Mon, 26 Mar 2012 11:22:21 +0200 schreef kishor <kiishor@gmail.com>:
> 	Hi friends,
> 	I am working on stellaris LM3s6965 (cortex-m3) & Keil 4.20 for data
> acquisition. ADC is signed 24-bit.
>
> 	To perform software Gain calibration I have two options,
>
> 	1. 64-bit fixed width arithmetic
> 		ADC_Reading = ((int64_t)ADC_Reading * Gain) / 0x8000;
> 	2. Single precision Float
> 		ADC_Reading = ADC_Reading * Gain;
>
> 		Which is better for performance wise[?]

An (u)int64_t multiplication is always faster than a float multiplication,  
assuming you don't have a hardware FPU.

Also, if you can deal with some loss of precision, you can pre-divide both  
operands enough to be able to use 32-bit multiplication.


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(Remove the obvious prefix to reply privately.)

[toc] | [prev] | [next] | [standalone]

#7763

On 03/26/2012 11:22 AM, kishor wrote:
> 	Hi friends,
> 	I am working on stellaris LM3s6965 (cortex-m3)&  Keil 4.20 for data
> acquisition. ADC
> 	is signed 24-bit.
>
> 	To perform software Gain calibration I have two options,
>
> 	1. 64-bit fixed width arithmetic
> 		uint16_t Gain;		// 0x8000 means gain is 1
> 		int32_t ADC_Reading;		// It contains 24-bit signed integer ADC
> reading
>
> 		ADC_Reading = ((int64_t)ADC_Reading * Gain) / 0x8000;           //
> Gain calibration

Cortex-M3 has a 32x32->64 bit multiply instruction, so if your compiler 
is smart enough, it might use that. Check the generated assembly output.

If not, write your own assembly version.

[toc] | [prev] | [next] | [standalone]

#7764

On 26/03/2012 13:14, Arlet Ottens wrote:
> On 03/26/2012 11:22 AM, kishor wrote:
>> Hi friends,
>> I am working on stellaris LM3s6965 (cortex-m3)& Keil 4.20 for data
>> acquisition. ADC
>> is signed 24-bit.
>>
>> To perform software Gain calibration I have two options,
>>
>> 1. 64-bit fixed width arithmetic
>> uint16_t Gain; // 0x8000 means gain is 1
>> int32_t ADC_Reading; // It contains 24-bit signed integer ADC
>> reading
>>
>> ADC_Reading = ((int64_t)ADC_Reading * Gain) / 0x8000; //
>> Gain calibration
>
> Cortex-M3 has a 32x32->64 bit multiply instruction, so if your compiler
> is smart enough, it might use that. Check the generated assembly output.
>
> If not, write your own assembly version.

Unless you require the absolutely fastest performance (and someone 
asking the original question clearly is not - or he would already have 
found the answer), do not write your own assembly code.  It's just 
pointless optimisation for optimisation's sake.

By all means, look at the generated assembly and see if it uses the 
ideal instruction.  If it doesn't, then file a report or support request 
with the compiler supplier if you want.

Don't do inline assembly unless you really have a reason for it, 
especially if you are not used to it.

[toc] | [prev] | [next] | [standalone]

#7766

Thanks for reply,

Compiler has generated "UMULL" instruction, (32-bit * 32-bit)
As it is signed multiplication it generated another three instructions.

Assembly listing is as below,

 r1 - ADC_Reading (signed)
 r2 - Gain (unsigned)

      UMULL    r0,r5,r1,r2            ; unsigned multiply 32 * 32
      ASRS     r3,r1,#31               ; Arithmetic Shift Right
      MLA      r2,r3,r2,r5              ; Multiply & Accumulate 
      MLA      r1,r1,r12,r2            ; Multiply & Accumulate 

      MOV      r2,#0x8000
      MOV      r3,r12

      BL       __aeabi_ldivmod     ; 64-bits divider function

So multiplication is not a big deal. signed 64-bit divide takes time.

So still is it better than float?

Thanks,
Kishore.

[toc] | [prev] | [next] | [standalone]

#7767

>-----< kishor >
> So multiplication is not a big deal. signed 64-bit divide takes time.

You don't need the division. You need to shift down 31 bits to get back 
to 32 bits.

Perhaps the ALU can do to all for you in one step. Check the compiler for 
a built-in function for 32-bit signed fractional multiplication.

Read up on fractional arithmetic.

-- 
Fredrik Östman

[toc] | [prev] | [next] | [standalone]

#7769

On Monday, March 26, 2012 6:08:00 PM UTC+5:30, Fredrik Östman wrote:

> You don't need the division. You need to shift down 31 bits to get back 
> to 32 bits.

I don't understand your point. In signed division we can't shift down bits simply.

> Perhaps the ALU can do to all for you in one step. Check the compiler for 
> a built-in function for 32-bit signed fractional multiplication.
> 
> Read up on fractional arithmetic.

Is there other method which avoids 64-bit division?


Kishore.

[toc] | [prev] | [next] | [standalone]

#7771

On 03/26/2012 03:33 PM, kishor wrote:
> On Monday, March 26, 2012 6:08:00 PM UTC+5:30, Fredrik Östman wrote:
>
>> You don't need the division. You need to shift down 31 bits to get back
>> to 32 bits.
>
> I don't understand your point. In signed division we can't shift down bits simply.

The difference is at most 1 LSB due to rounding differences, which is 
probably less than your ADC noise.

You can make the difference even smaller by using a 32 bit gain variable.

You could also find out if ADC value is negative, reverse the sign, 
perform unsigned arithmetic, and reverse the sign of the result.

[toc] | [prev] | [next] | [standalone]

#7772

On 26/03/2012 15:33, kishor wrote:
> On Monday, March 26, 2012 6:08:00 PM UTC+5:30, Fredrik Östman wrote:
>
>> You don't need the division. You need to shift down 31 bits to get
>> back to 32 bits.
>
> I don't understand your point. In signed division we can't shift down
> bits simply.

Correct.

But the compiler should do the strength reduction for you - take note of 
the sign, do everything unsigned, then restore the sign.  If it doesn't, 
then check your optimisation settings and/or complain to the supplier.

>
>> Perhaps the ALU can do to all for you in one step. Check the
>> compiler for a built-in function for 32-bit signed fractional
>> multiplication.
>>
>> Read up on fractional arithmetic.
>
> Is there other method which avoids 64-bit division?
>

Yes - do everything unsigned.  First think if the incoming data really 
is signed - in most cases it is not.  But if you have signed data (say 
from a differential input), first note the sign then convert to a 
positive value if needed.  Then do your scaling and division (and if the 
compiler can't convert an unsigned divide by 0x8000 to a shift, it's a 
poor compiler - and you can do the shift by hand).  Then restore the sign.

[toc] | [prev] | [next] | [standalone]

#7773

>-----< kishor >
> I don't understand your point. In signed division we can't shift down
> bits simply.

In fractional representation (all numbers are between -1 and 1) we can 
and we do.

-- 
Fredrik Östman

[toc] | [prev] | [next] | [standalone]

#7770

On 03/26/2012 02:24 PM, kishor wrote:
> Thanks for reply,
>
> Compiler has generated "UMULL" instruction, (32-bit * 32-bit)
> As it is signed multiplication it generated another three instructions.
>
> Assembly listing is as below,
>
>   r1 - ADC_Reading (signed)
>   r2 - Gain (unsigned)
>
>        UMULL    r0,r5,r1,r2            ; unsigned multiply 32 * 32
>        ASRS     r3,r1,#31               ; Arithmetic Shift Right
>        MLA      r2,r3,r2,r5              ; Multiply&  Accumulate
>        MLA      r1,r1,r12,r2            ; Multiply&  Accumulate
>
>        MOV      r2,#0x8000
>        MOV      r3,r12
>
>        BL       __aeabi_ldivmod     ; 64-bits divider function
>
> So multiplication is not a big deal. signed 64-bit divide takes time.
>
> So still is it better than float?

Try doing a >> 15 instead of a / 0x8000 in your C code.

[toc] | [prev] | [next] | [standalone]

#7774

On Mon, 26 Mar 2012 15:34:37 +0200, Arlet Ottens wrote:

> On 03/26/2012 02:24 PM, kishor wrote:
>> Thanks for reply,
>>
>> Compiler has generated "UMULL" instruction, (32-bit * 32-bit) As it is
>> signed multiplication it generated another three instructions.
>>
>> Assembly listing is as below,
>>
>>   r1 - ADC_Reading (signed)
>>   r2 - Gain (unsigned)
>>
>>        UMULL    r0,r5,r1,r2            ; unsigned multiply 32 * 32 ASRS
>>            r3,r1,#31               ; Arithmetic Shift Right MLA     
>>        r2,r3,r2,r5              ; Multiply&  Accumulate MLA     
>>        r1,r1,r12,r2            ; Multiply&  Accumulate
>>
>>        MOV      r2,#0x8000
>>        MOV      r3,r12
>>
>>        BL       __aeabi_ldivmod     ; 64-bits divider function
>>
>> So multiplication is not a big deal. signed 64-bit divide takes time.
>>
>> So still is it better than float?
> 
> Try doing a >> 15 instead of a / 0x8000 in your C code.

But note that ANSI C leaves the contents of the most significant bits of 
a right-shift of a negative number up to the implementor -- it is equally 
valid within ANSI-C specs to shift in zeros (affecting both sign and 
magnitude) as it is to shift in ones.

The only reliable way to do this across compilers (and even major 
revisions) is to convert to unsigned, shift (unsigned right shifts always 
shift in zeros), then restore the sign as necessary.

It should be habit.  Never right-shift a signed number when it might be 
positive.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#7777

On 03/26/2012 07:25 PM, Tim Wescott wrote:
> On Mon, 26 Mar 2012 15:34:37 +0200, Arlet Ottens wrote:
>
>> On 03/26/2012 02:24 PM, kishor wrote:
>>> Thanks for reply,
>>>
>>> Compiler has generated "UMULL" instruction, (32-bit * 32-bit) As it is
>>> signed multiplication it generated another three instructions.
>>>
>>> Assembly listing is as below,
>>>
>>>    r1 - ADC_Reading (signed)
>>>    r2 - Gain (unsigned)
>>>
>>>         UMULL    r0,r5,r1,r2            ; unsigned multiply 32 * 32 ASRS
>>>             r3,r1,#31               ; Arithmetic Shift Right MLA
>>>         r2,r3,r2,r5              ; Multiply&   Accumulate MLA
>>>         r1,r1,r12,r2            ; Multiply&   Accumulate
>>>
>>>         MOV      r2,#0x8000
>>>         MOV      r3,r12
>>>
>>>         BL       __aeabi_ldivmod     ; 64-bits divider function
>>>
>>> So multiplication is not a big deal. signed 64-bit divide takes time.
>>>
>>> So still is it better than float?
>>
>> Try doing a>>  15 instead of a / 0x8000 in your C code.
>
> But note that ANSI C leaves the contents of the most significant bits of
> a right-shift of a negative number up to the implementor -- it is equally
> valid within ANSI-C specs to shift in zeros (affecting both sign and
> magnitude) as it is to shift in ones.

I agree that a right shift on a negative value is implementation 
defined, but it's very unlikely that a compiler for Cortex M3 would not 
use the arithmetic shift right instruction.

If you're really paranoid, you could build in a run-time check at 
program initialization for expected right shift behavior.

[toc] | [prev] | [next] | [standalone]

#7781

On Mon, 26 Mar 2012 20:19:56 +0200, Arlet Ottens <usenet+5@c-scape.nl>
wrote:

>On 03/26/2012 07:25 PM, Tim Wescott wrote:
>> On Mon, 26 Mar 2012 15:34:37 +0200, Arlet Ottens wrote:
>>
>>> On 03/26/2012 02:24 PM, kishor wrote:
>>>> Thanks for reply,
>>>>
>>>> Compiler has generated "UMULL" instruction, (32-bit * 32-bit) As it is
>>>> signed multiplication it generated another three instructions.
>>>>
>>>> Assembly listing is as below,
>>>>
>>>>    r1 - ADC_Reading (signed)
>>>>    r2 - Gain (unsigned)
>>>>
>>>>         UMULL    r0,r5,r1,r2            ; unsigned multiply 32 * 32 ASRS
>>>>             r3,r1,#31               ; Arithmetic Shift Right MLA
>>>>         r2,r3,r2,r5              ; Multiply&   Accumulate MLA
>>>>         r1,r1,r12,r2            ; Multiply&   Accumulate
>>>>
>>>>         MOV      r2,#0x8000
>>>>         MOV      r3,r12
>>>>
>>>>         BL       __aeabi_ldivmod     ; 64-bits divider function
>>>>
>>>> So multiplication is not a big deal. signed 64-bit divide takes time.
>>>>
>>>> So still is it better than float?
>>>
>>> Try doing a>>  15 instead of a / 0x8000 in your C code.
>>
>> But note that ANSI C leaves the contents of the most significant bits of
>> a right-shift of a negative number up to the implementor -- it is equally
>> valid within ANSI-C specs to shift in zeros (affecting both sign and
>> magnitude) as it is to shift in ones.
>
>I agree that a right shift on a negative value is implementation 
>defined, but it's very unlikely that a compiler for Cortex M3 would not 
>use the arithmetic shift right instruction.
>
>If you're really paranoid, you could build in a run-time check at 
>program initialization for expected right shift behavior.

Why not do an explicit divide by 2 (or 4 or 8 or ...)? Surely most
modern compilers are smart enough to recognize that this can be
accomplished via an arithmetic right shift if the processor supports
such an instruction or a "logical right shift" (zero filled) followed by
stuffing ones up topside if the old MSB was set and the type was signed.

Just curious.

-- 
Rich Webb     Norfolk, VA

[toc] | [prev] | [next] | [standalone]

#7784

On Mon, 26 Mar 2012 16:45:27 -0400, Rich Webb wrote:

> On Mon, 26 Mar 2012 20:19:56 +0200, Arlet Ottens <usenet+5@c-scape.nl>
> wrote:
> 
>>On 03/26/2012 07:25 PM, Tim Wescott wrote:
>>> On Mon, 26 Mar 2012 15:34:37 +0200, Arlet Ottens wrote:
>>>
>>>> On 03/26/2012 02:24 PM, kishor wrote:
>>>>> Thanks for reply,
>>>>>
>>>>> Compiler has generated "UMULL" instruction, (32-bit * 32-bit) As it
>>>>> is signed multiplication it generated another three instructions.
>>>>>
>>>>> Assembly listing is as below,
>>>>>
>>>>>    r1 - ADC_Reading (signed)
>>>>>    r2 - Gain (unsigned)
>>>>>
>>>>>         UMULL    r0,r5,r1,r2            ; unsigned multiply 32 * 32
>>>>>         ASRS
>>>>>             r3,r1,#31               ; Arithmetic Shift Right MLA
>>>>>         r2,r3,r2,r5              ; Multiply&   Accumulate MLA
>>>>>         r1,r1,r12,r2            ; Multiply&   Accumulate
>>>>>
>>>>>         MOV      r2,#0x8000
>>>>>         MOV      r3,r12
>>>>>
>>>>>         BL       __aeabi_ldivmod     ; 64-bits divider function
>>>>>
>>>>> So multiplication is not a big deal. signed 64-bit divide takes
>>>>> time.
>>>>>
>>>>> So still is it better than float?
>>>>
>>>> Try doing a>>  15 instead of a / 0x8000 in your C code.
>>>
>>> But note that ANSI C leaves the contents of the most significant bits
>>> of a right-shift of a negative number up to the implementor -- it is
>>> equally valid within ANSI-C specs to shift in zeros (affecting both
>>> sign and magnitude) as it is to shift in ones.
>>
>>I agree that a right shift on a negative value is implementation
>>defined, but it's very unlikely that a compiler for Cortex M3 would not
>>use the arithmetic shift right instruction.
>>
>>If you're really paranoid, you could build in a run-time check at
>>program initialization for expected right shift behavior.
> 
> Why not do an explicit divide by 2 (or 4 or 8 or ...)? Surely most
> modern compilers are smart enough to recognize that this can be
> accomplished via an arithmetic right shift if the processor supports
> such an instruction or a "logical right shift" (zero filled) followed by
> stuffing ones up topside if the old MSB was set and the type was signed.
> 
> Just curious.

Actually, your answer was in the context you included: the OP's machine 
code shows a divide function being called, with 0x8000 as the denominator.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#7785

On Mon, 26 Mar 2012 17:15:44 -0500, Tim Wescott <tim@seemywebsite.com>
wrote:

>On Mon, 26 Mar 2012 16:45:27 -0400, Rich Webb wrote:
>
>> On Mon, 26 Mar 2012 20:19:56 +0200, Arlet Ottens <usenet+5@c-scape.nl>
>> wrote:
>> 
>>>On 03/26/2012 07:25 PM, Tim Wescott wrote:
>>>> On Mon, 26 Mar 2012 15:34:37 +0200, Arlet Ottens wrote:
>>>>
>>>>> On 03/26/2012 02:24 PM, kishor wrote:
>>>>>> Thanks for reply,
>>>>>>
>>>>>> Compiler has generated "UMULL" instruction, (32-bit * 32-bit) As it
>>>>>> is signed multiplication it generated another three instructions.
>>>>>>
>>>>>> Assembly listing is as below,
>>>>>>
>>>>>>    r1 - ADC_Reading (signed)
>>>>>>    r2 - Gain (unsigned)
>>>>>>
>>>>>>         UMULL    r0,r5,r1,r2            ; unsigned multiply 32 * 32
>>>>>>         ASRS
>>>>>>             r3,r1,#31               ; Arithmetic Shift Right MLA
>>>>>>         r2,r3,r2,r5              ; Multiply&   Accumulate MLA
>>>>>>         r1,r1,r12,r2            ; Multiply&   Accumulate
>>>>>>
>>>>>>         MOV      r2,#0x8000
>>>>>>         MOV      r3,r12
>>>>>>
>>>>>>         BL       __aeabi_ldivmod     ; 64-bits divider function
>>>>>>
>>>>>> So multiplication is not a big deal. signed 64-bit divide takes
>>>>>> time.
>>>>>>
>>>>>> So still is it better than float?
>>>>>
>>>>> Try doing a>>  15 instead of a / 0x8000 in your C code.
>>>>
>>>> But note that ANSI C leaves the contents of the most significant bits
>>>> of a right-shift of a negative number up to the implementor -- it is
>>>> equally valid within ANSI-C specs to shift in zeros (affecting both
>>>> sign and magnitude) as it is to shift in ones.
>>>
>>>I agree that a right shift on a negative value is implementation
>>>defined, but it's very unlikely that a compiler for Cortex M3 would not
>>>use the arithmetic shift right instruction.
>>>
>>>If you're really paranoid, you could build in a run-time check at
>>>program initialization for expected right shift behavior.
>> 
>> Why not do an explicit divide by 2 (or 4 or 8 or ...)? Surely most
>> modern compilers are smart enough to recognize that this can be
>> accomplished via an arithmetic right shift if the processor supports
>> such an instruction or a "logical right shift" (zero filled) followed by
>> stuffing ones up topside if the old MSB was set and the type was signed.
>> 
>> Just curious.
>
>Actually, your answer was in the context you included: the OP's machine 
>code shows a divide function being called, with 0x8000 as the denominator.

Aha! Damn that automatic quote-folding feature...

-- 
Rich Webb     Norfolk, VA

[toc] | [prev] | [next] | [standalone]

#7791

Sorry for late reply,

I have experimented few things,

1. Signed 32-bit divide by constant of 2^n
     Compiler uses 2 ASR (Arithmetic shift right) & 1 ADD instruction instead of SDIV instruction

2. Signed 32-bit divide by  constant other than 2^n
    It uses SMLAL (signed multiply & accumulate long) & other instructions

3. Unsigned 64-bit divide by constant of 2^n
    It uses 2 LSR & 1 ORR instruction.

4. Unsigned 64-bit divide by constant other than 2^n
5. Signed 64-bit divide by constant of 2^n
6. Signed 64-bit divide by  constant other than 2^n

  It calls __aeabi_ldivmod, __aeabi_uldivmod functions 

I have two queries,

1. Is hardware DIV / SDIV instructions are slower than shift logic?
2. Is it possible to generate shift based logic to case 5 mentioned above?
(Signed 64-bit divide by constant of 2^n)

Thanks,
Kishore.

[toc] | [prev] | [next] | [standalone]

#7794

On 27/03/2012 13:59, kishor wrote:
> Sorry for late reply,
>
> I have experimented few things,
>
> 1. Signed 32-bit divide by constant of 2^n
>       Compiler uses 2 ASR (Arithmetic shift right)&  1 ADD instruction instead of SDIV instruction
>
> 2. Signed 32-bit divide by  constant other than 2^n
>      It uses SMLAL (signed multiply&  accumulate long)&  other instructions
>
> 3. Unsigned 64-bit divide by constant of 2^n
>      It uses 2 LSR&  1 ORR instruction.
>
> 4. Unsigned 64-bit divide by constant other than 2^n
> 5. Signed 64-bit divide by constant of 2^n
> 6. Signed 64-bit divide by  constant other than 2^n
>
>    It calls __aeabi_ldivmod, __aeabi_uldivmod functions
>
> I have two queries,
>
> 1. Is hardware DIV / SDIV instructions are slower than shift logic?

Yes.  DIV instructions take several cycles (I don't know how many for 
the M3), and will cause pipeline stalls which reduce the throughput of 
other instructions.  Shifts are therefore faster, even if they need a 
few other instructions around them.  It is also faster to multiply by a 
scaled pre-calculated reciprocal (case 2 above).

> 2. Is it possible to generate shift based logic to case 5 mentioned above?
> (Signed 64-bit divide by constant of 2^n)

Yes.

The easiest way to make sure you get signed division right is to 
separate out the sign, then use unsigned arithmetic.  That way you can't 
go wrong, and the C code is portable.

>
> Thanks,
> Kishore.
>
>

[toc] | [prev] | [next] | [standalone]

#7834

On Tue, 27 Mar 2012 15:25:21 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:
>
>> 2. Is it possible to generate shift based logic to case 5 mentioned above?
>> (Signed 64-bit divide by constant of 2^n)
>
>Yes.
>
>The easiest way to make sure you get signed division right is to 
>separate out the sign, then use unsigned arithmetic.  That way you can't 
>go wrong, and the C code is portable.

Additional note to the OP:  comp.lang.c will point you in the right
direction as far as what is portable and what is not.

From memory, probably wrong ... I should look it up, but too lazy.

For unsigneds, no issues shifting in either direction.  Works as
intuitively expected.

For signeds ...

Signed left shifts work as expected.  0 is always propagated into the
LSB.

Signed right shifts are, from memory, I believe, implementation
dependent.  It isn't guaranteed how the MSB will be populated.

Again, this is from memory and possibly wrong.

The suggestion of separating out the sign certainly prudent.

DTA

[toc] | [prev] | [next] | [standalone]

#7787

kishor wrote:

> Hi friends,
> I am working on stellaris LM3s6965 (cortex-m3) & Keil 4.20 for data
> acquisition. ADC
> is signed 24-bit.

Except when the numbers really do get to be too ridiculously large or wide 
ranging to handle doing the calculations by long fractions will tend to be 
faster for most instrumentation needs.

It is always best to look closely at the various ways you can implement your 
calculations. Gains are easy by fractions (width limited multiplies that 
discard the least significant bits). Calibration curves can often be done by 
Polynomial Approximations (see Hastings reference).

"Approximations for Digital Computers" by Cecil Hastings Jr., T. Hayward, 
James P. Wong Jr.	ISBN 0-691-07914-5

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web