嵌入式C Cortex-M4：正确处理大数除法吗？

Question

I'm writing embedded code for spectroscopy. In order to build my spectrum, I need to map linearly samples from an interval (dynamic range is given by the physics/specs of the problem) to another. Basically after data is processed I have a series of samples (peaks) and every one of them will contribute to the spectrum (ie will increment the counter of a specific bin in a histogram). Here's a sketch: So in C, I need to map each peak value into the [0:4095] and I'm doing this in real-time on a MCU (LPC4370) so I need to go fast. The problem is that my dumb implementation is squeezing everything to 0. here's what i did:

 #define MCA_SIZE     4096
 #define PEAK_MAX     1244672762
 #define PEAK_MIN     6000000

 int32_t mca[MCA_SIZE];
 int32_t peak_val;
 int32_t bin_val;

[...]

 if(peak_val > PEAK_MIN)
      {
       bin_val = (int)(MCA_SIZE*(peak_val-PEAK_MIN)/(PEAK_MAX-PEAK_MIN));

       /*Increment corrispondent multi channel bin*/
       mca[bin_val]+=1;
      };

Where every quantity is int32 if lower cas, #define is upper case. The problem is that is believe this one

(peak_val-PEAK_MIN)/(PEAK_MAX-PEAK_MIN)

Goes very often near zero. So I end-up having just the first one or two bins filled.

Here's a screenshot of first values of mca after few thousand iterations:

Here's the disassbly view of the code under study, along with register status at breakpoint.

What is the best/fastest way to handle this kind of problem?

Answer 1

The intermediate result (MCA_SIZE*(peak_val-PEAKMIN)) is too large for a 32-bit integer datatype. I would use uint64_t for these calculations, and I would define all of your constants as const uint64_t rather than using a #define , adding a suffix of ULL to their literal values.

Answer 2

Please note that your code is likely to produce signed integer overflow, which is undefined in the standard.

From the C99 standard (§3.4.3/1)

An example of undefined behavior is the behavior on integer overflow

So I would start there, either move to unsigned, use a wider type or change the boundaries.

Also, as user6556709 mentioned in it's comment, the expression:

(MCA_SIZE*(peak_val-PEAK_MIN)/(PEAK_MAX-PEAK_MIN))

Is guaranteed to be executed as if it was written as follows, due to left-to-right associativity for those group of operators (note the parentheses):

((MCA_SIZE*(peak_val-PEAK_MIN))/(PEAK_MAX-PEAK_MIN))

So the always-zero-evaluated expression (peak_val-PEAK_MIN)/(PEAK_MAX-PEAK_MIN) is not performed, the expression (MCA_SIZE*(peak_val-PEAK_MIN)) is done prior, so that is not the main problem.

I would recommend providing some examples for peak_val in which bins are not filled.