-4

Please consider this bit of assembly code:

 924:   70 e0           ldi r23, 0x00   ; store 0 in r23
 926:   76 2f           mov r23, r22    ; copy r22's value to r23

(It was generated by avr-gcc with the (default) -Os option active.)

Why does it do this? It makes no sense that I can fathom, to first store 0x00 in r23 and then overwrite r23 with r22.

Waste of a clock cycle, and memory space, in my humble opinion.

This is not a singular occurrence though, it happens all over the place.

Sometimes even:

eor r2, r2   ; zero r2
mov r2, r18  ; copy r18 to r2

occurs.

Why?

(Before you answer, I know that in the latter example of the "extraneous" instructions, the zero flag is set, yet is ignored or changed, by the code following it.)

Any software update, that has been compiled with a "new" and "better" compiler, eliminating the extra codes, therefore yields a speed increase, without changing the source code itself.

This stinks.

Nay, it reeks.

I'm curious if you have had the same experience, and opted to use inline assembly yourself, because the compiler just couldn't "cut it".

Thanks for your feedback.

the busybee
  • 10,755
  • 3
  • 13
  • 30
I Think before I am
  • 1
  • 1
    Please post the instruction either side of those. And you should be able to see which source line is the culprit. – Rohit Gupta Aug 16 '23 at 20:37
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. –  Aug 16 '23 at 20:37
  • 4
    Compilers are not perfect so it may be missed optimization but it's hard to tell without the source code. Also you might want to tone down the language a little. PS: avr is not arm. – Jester Aug 16 '23 at 20:53
  • I am asking why the avr-gcc compiler (7.3.0-atmel3.6.1-arduino7) thinks it is necessary to first empty a register variable, wasting 1 clock cycle and two bytes of memory, before assigning it another value. (without even an cli statement, so the whole exercise is moot.) Also both AVR and ARM are RISC based. The mnemonics I used are compatible with both. This behaviour is throughout, if you want to observe it, try compiling arduino's blink.ino example, and dissasemble the code yourself. You will see what I mean popping up everywhere, this is not an isolated incident. – I Think before I am Aug 16 '23 at 21:38
  • 2
    Actually arm doesn't have a `ldi`. Anyway, I tried the blink example on godbolt and I see no such problems. Note that it uses library functions which have already been compiled and are just linked in and the compiler can't do anything about those. I even took the library functions and compiled them without issues. Until you can provide a specific example, that's the best I can do. – Jester Aug 16 '23 at 21:58
  • 3
    Probably about one in a million claims of "compiler error" are actually a compiler error. But maybe you're that "one". Show us your code. Is it C? No language is tagged. – pmacfarlane Aug 16 '23 at 22:53
  • 2
    If it's so common, you should have no trouble producing a *very* short [mcve] of a source file that you compile with a specific compiler version, to get a complete object file that you can show disassembly for. (Or compiler asm output, preferably with a link to it on https://godbolt.org/ if those GCC versions can reproduce this). But Jester said they couldn't reproduce this with AVR GCC on godbolt, so include details about where you got your compiler from, and `-v` version + config output for it. – Peter Cordes Aug 16 '23 at 23:41
  • Please take the [tour] to learn how this site works. This is not a forum where you discuss things in comments. Add new information directly in the question by [edit]ing it. We use comments to ask for clarification and to suggest enhancements of your question. – the busybee Aug 17 '23 at 06:44

0 Answers0