little problem of optimisations with gcc

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I am testing avr-gcc for my project with atMega8L device and I detected a little problem of optimisation with gcc: a partial code generated given:

38:driverXe.c **** volatile char tempo = wordToSend.word>>8;
87 .stabn 68,0,38,.LM2-_spi_
88 .LM2:
89 .LBB2:
90 001c 8091 0000 lds r24,wordToSend
91 0020 9091 0000 lds r25,(wordToSend)+1
92 0024 892F mov r24,r25
93 0026 9927 clr r25
...

instead something:
lds r24,(wordToSend)+1
...

optimisation choosen is -Os

Is somebody has an idee for to choose a good option of gcc which permit to avoid this behavior. (Other idea is to declare an union with a low and high byte and a word, but I want a very simple code.). Thank you in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you can quickly try to use O1, O2, O3, O4
for me the higher optimisations had not so disirable side effects.
If you really need that optimised code in this spot, you'll probably should code it in assambler anyway?

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gcc I think cannot optimize this.

Instructions
90 001c 8091 0000 lds r24,wordToSend
91 0020 9091 0000 lds r25,(wordToSend)+1

load value into register,
next two
92 0024 892F mov r24,r25
93 0026 9927 clr r25
represent logical shift right (providing structure member 'word' is unsigned 16 bits).
So, instructions are:
movhi - move data to reg
lshrhi - shift reg

This is valid for any 8 bit gcc implementation.

For 16 bit core (msp430 for example) gcc does:
mov.b &wordToSend+1, r15
mov.b r15, &tempo

Here first insn is 'zero extend' char to int 16 bit,
and second one just stores value of tempo.

So, I think, if you wanna optimize it, just write assembler code.

Hope it helps,
Dmitry.

admin's test signature