AVR Freaks

It seems to defeat some optimizations or something.   The asm() statement doesn't produce any code, but the compiler output changes anyway...

With tick:

make atmega328
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_495) 5.4.0
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=3              -c -o optiboot.o optiboot.c
avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L  -DBAUD_RATE=115200 -DLED_START_FLASHES=3            -Wl,--section-start=.text=0x7e00 -Wl,--section-start=.version=0x7ffe -Wl,--relax -nostartfiles -o optiboot_atmega328.elf optiboot.o
avr-size optiboot_atmega328.elf
   text    data     bss     dec     hex filename
    490       0       0     490     1ea optiboot_atmega328.elf

Without tick:

avr-size optiboot_atmega328.elf
   text    data     bss     dec     hex filename
    482       0       0     482     1e2 optiboot_atmega328.elf

It looks like pretty subtle optimization issues.  Here's the first difference from the existing program.  I don't know if I'll be able to make a small example. (I'll try...)

;; Source code.

    else if(ch == STK_SET_DEVICE) {
      // SET DEVICE is ignored
      getNch(20); 
      TICK(set_device_size);
   }
    else if(ch == STK_SET_DEVICE_EXT) {
      // SET DEVICE EXT is ignored
      getNch(5);
      TICK(size_setdevext);
    }
    else if(ch == STK_LOAD_ADDRESS) {
      // LOAD ADDRESS
      address.bytes[0] = getch();
      address.bytes[1] = getch();
      :


;;Without TICK macro:
;;
    else if(ch == STK_SET_DEVICE) {
    7e9c:	82 34       	cpi	r24, 0x42	; 66
      getNch(20); 
;;; ***HERE*** the compiler detects common "tail" (getNch, goto end of loop)
    7e9e:	11 f4       	brne	.+4      	; 0x7ea4 <main+0xa0>
    7ea0:	84 e1       	ldi	r24, 0x14	; 20
    else if(ch == STK_SET_DEVICE_EXT) {
    7ea2:	03 c0       	rjmp	.+6      	; 0x7eaa <main+0xa6>
      getNch(5);
    7ea4:	85 34       	cpi	r24, 0x45	; 69
    7ea6:	19 f4       	brne	.+6      	; 0x7eae <main+0xaa>
    7ea8:	85 e0       	ldi	r24, 0x05	; 5
    else if(ch == STK_LOAD_ADDRESS) {
    7eaa:	83 d0       	rcall	.+262    	; 0x7fb2 <getNch>
    7eac:	5e c0       	rjmp	.+188    	; 0x7f6a <main+0x166>


;; With TICK macro defined:
;;
    else if(ch == STK_SET_DEVICE) {
    7e9c:	82 34       	cpi	r24, 0x42	; 66
      getNch(20); 
    7e9e:	19 f4       	brne	.+6      	; 0x7ea6 <main+0xa2>
    7ea0:	84 e1       	ldi	r24, 0x14	; 20
      TICK(set_device_size);
;;;  ***HERE*** we get the getNch, rjmp main+0x16e twice.
    7ea2:	8b d0       	rcall	.+278    	; 0x7fba <getNch>
    else if(ch == STK_SET_DEVICE_EXT) {
    7ea4:	66 c0       	rjmp	.+204    	; 0x7f72 <main+0x16e>
      getNch(5);
    7ea6:	85 34       	cpi	r24, 0x45	; 69
    7ea8:	19 f4       	brne	.+6      	; 0x7eb0 <main+0xac>
      TICK(size_setdevext);
    7eaa:	85 e0       	ldi	r24, 0x05	; 5
    else if(ch == STK_LOAD_ADDRESS) {
    7eac:	86 d0       	rcall	.+268    	; 0x7fba <getNch>
      address.bytes[0] = getch();
    7eae:	61 c0       	rjmp	.+194    	; 0x7f72 <main+0x16e>

when you measure something, you change it!  Looks like that holds for software too!

Oh, certainly!  We even had a name for them at my last employer: "Heisenbugs"

However, all basic asm statements are implicitly volatile:

I had not realized that.  Hmm.

you may want to use extended asm to see if it makes a difference.

However...  No difference.

The other seven bits of SREG are implicitly clobbered as a result of the inline assembly implementation.

Ah.  This sounds like a likely culprit.

The implementation change  to keep avr-gcc away from the headsman would unclobber the above seven bits.

And thank you for providing a bit of insight as to what that whole change is about!

it may read or write any globally accessible variable.

 I'm not sure that the code has anything that the compiler would think is a "globally accessible variable."  SFRs?  The example in https://www.avrfreaks.net/commen... is all registers...

I've uploaded a stripped and cleaned copy of the code/makefile to https://github.com/WestfW-patche...

(It's still all of atmega328 optiboot; i just deleted a lot of the code and conditionals for options and other processors to make things clearer.)
(I hope to make additional changes and provide additional annotated output files to make it easier to look at the problem, but this is a start.)

Would the .s from the unsprinkled code work if SREG and R0 were clobbered by imaginary sprinkles?

I actually don't think so.  r0 only seems to get used by inner-loop spm-related stuff, and the code that's getting longer is pretty much a string of if/elseif statements continually resetting SREG.

(oops.  I got the sense of the question wrong.   I think the code would work fine if the macros clobbered SREG.)