different execution time between loclal variable and static structure - structure

Question

I write a program on AVR's microcontrolers. It should check actual temperature and show it on 7-segment display. And this the problem which I have: I made a structure with all variables referd to temperature (temperature, pointer position, sign and unit) and saw that the execution time of e.g. dividing by 10 or mod 10 is much more longer then when i use normal local variable. I dont know why. I use Atmel Studio 6.2.
struct dane
{
int32_t temperature;
int8_t pointer;
int8_t sign;
int8_t unit;
};
//************************************
//inside function of timer interrupt
static struct dane present;
//*****************************
//tested operations:
present.temperature % 10; //execution time: ~380 processor's cycles, on normal local variable ~4 cycles.
present.temperature /= 10; //execution time: ~611 cycles
I give you this function where I use it and a little bit of assembly code.
ISR(TIMER0_OVF_vect)
{
static int8_t i = 4;
static struct dane present;
if(i == 4 && (TCCR0 & (1 << CS01)))
{
i = 0;
present = current;
if(present.temperature < 0)
present.temperature = -present.temperature;
}
if((TCCR0 & ((1 << CS00) | (1 << CS02))) && i != 0)
{
i = 0;
}
if(present.unit == current.unit) //time between here and fist instruction in function print equals about 300 cycles.
{
print((i * present.sign == 3 && present_temperature % 10 == 0) ? 16 : present_temperature % 10, displays[i], i == present.pointer);
}
else
{
print(current.unit, displays[i],0);
if(i == 4)
{
i = 3;
TCCR0 = (1 << CS01);
present.unit = current.unit;
}
}
present.temperature /= 10;
i++;
}
And assembly code for the one before last instruction:
present.temperature /= 10;
0000021F LDI R28,0x7D Load immediate
00000220 LDI R29,0x00 Load immediate
00000221 LDD R22,Y+0 Load indirect with displacement
00000222 LDD R23,Y+1 Load indirect with displacement
00000223 LDD R24,Y+2 Load indirect with displacement
00000224 LDD R25,Y+3 Load indirect with displacement
00000225 LDI R18,0x0A Load immediate
00000226 LDI R19,0x00 Load immediate
00000227 LDI R20,0x00 Load immediate
00000228 LDI R21,0x00 Load immediate
00000229 RCALL PC+0x01AC Relative call subroutine
0000022A STD Y+0,R18 Store indirect with displacement
0000022B STD Y+1,R19 Store indirect with displacement
0000022C STD Y+2,R20 Store indirect with displacement
0000022D STD Y+3,R21 Store indirect with displacement
I can't use int16_t for temperature because I use the same structure inside function which coverts the temperature from the sensor and it is easier to operate on number with decimal part when I multiply it by 10 powered by suitable number.

Answer 1

There must be something wrong with your timings:
present.temperature % 10; //execution time: ~380 processor's cycles, on normal local variable ~4 cycles.
present.temperature /= 10; //execution time: ~611 cycles
A modulo-10 operation for a 32-bit value is never going to happen in 4 clock cycles with an AVR. The 380 cycles sounds a lot, but it is more realistic for a 32:32 division operation. I am afraid even an integer division on an AVR will take a lot of time with long integers.
It is quite natural that operations on module static variables take a bit longer, because they have to be fetched and stored in the RAM. This takes maybe 10 extra clock cycles per byte when compared to register variables (local variables are often in a register. The variable being in a struct should not change the timings at all in a case like this (with pointers to structs it may have an effect).
The only real way to get to know what is happening is to look at the assembly code produced by the compiler in each case.
And, please, include a minimal but complete example of both cases in your question. Then it is easier to see if there is something clearly wrong.
If you are interested in making your code faster, I suggest you try to use int16_t for the temperature. Your dynamic range in temperature measurement is hardly more than 12 bits (that would be, e.g., 0.1 °C for temperatures between -100°C..+300°C.) so that 16-bit ints should be sufficient.