Handling greater than 32-bit value in STM32

[Md_Aslam]

I am using STM32L073RZ for reading the data of some devices, after reading the raw data, which is 32-bit in length, I need to do some calculations which involve multiplications of the 32-bit values.
When I multiply the values then sometimes results cross the 32-bit limit which is 4294967296, So my question is how I can handle the values more than 32-bit in STM32 as this is a 32-bit microcontroller?

PS: The same question is for AVR also.

[ataradov]

Code: [Select]

uint32_t a = 1234567;
uint32_t b = 1234567890;
uint64_t res = (uint64_t)a * b;

Same for AVR, except the resulting code would be pretty inefficient.

[mariush]

Unless you're writing assembler, you shouldn't have to worry about it.
The C compiler should automatically handle this for you, just define a 64 bit variable (double or whatever the data type is) and store the result in that variable.

Alternatively, you could just split every number into a 24 bit part and a 8 bit remainder

ex  400 x 5  = (256 + 144) x 5  ->  400 >>8  = 1  , 400 & 0xFF = 144    - >  (1 x 5)  * 256  + 144*5

and when you make the additions you can add an extra check to not overflow.

a * b  = (a1 + a2) x (b1 + b2)  = a1b1 + a1b2 + a2b1 + a2b2

400*5  = (256 + 144) x(0 + 5) = 256*5 + 144*5

[ajb]

One thing to watch out for, since a single 64 bit operation requires executing multiple 32 bit instructions, they are not atomic, take longer to complete, and take two load/store operations for each operand and the result.  All of that means that a 64 bit operation has a much greater risk of being disrupted by an interrupt or if a value is otherwise modified while the operation is ongoing.

Of course this isn't a problem that only appears when you go above the native width of the architecture--any computation that requires multiple steps on shared values is susceptible--but a program that works with 32 bit types can suddenly start failing in bizarre and spectacular ways when converted to 64 bit operations if this has not been taken into account.  Fortunately there are straightforward methods for dealing with this in most cases, and many toolchains/libraries/OS implementations provide convenient tools for enforcing atomicity where required. 

[SiliconWizard]

You're right. That said, expecting any particular *C statement* to yield an atomic operation on a given target is a bad approach anyway in general. C is not assembly.
Heck, I should say that it's not "machine language", even. Because even when using assembly, some mnemonics may actually yield several actual CPU opcodes, so even in assembly, you need to be careful about that.

And now for the treat: you can use atomic types in C if you're using C11. You need to check whether they are implemented for your particular target.