AVR Freaks

If we don't change R0,R1 in ISR not need to back them up.

The HARDWARE may change them in some cases as the result of MUL is stored there.

I would not use them at all, I think R1 is expected to be zero pretty much at all times with the compiler to save time in some operation.

The complier generates this, even though the ISR is empty

[why couldn't I hit Quote under that post?]

Old news.  I gave links with the discussion of the null ISR.  GCC has been at least semi-smart for some time.

I want to sprinkle some assembly at places in C program where it is slow/can be improved ...

I still want some examples of that.  While examining and critiquing generated code at the low level is indeed vital, you cannot just do a peephole without full context.

Tell version and build options and target model.

5.4.0:

11.1.0:

(in fact if you go back through Godbolt versions you'll see this in their 9.x too - I think it was actually introduced at gcc 8 in fact).

What is now generated are special Asm macros. These do need you to be using a later Binutils so the avr-as assembler understands it but basically you will end up with a virtually empty ISR code as this great fix by Georg-Johann Lay ("SprinterSB") does not simply generate that "preserve SREG, CLR R1" stuff every time unless it is actually needed.

EDIT: confirm fixed in V8 : https://gcc.gnu.org/bugzilla/sho... if you follow the links you arrive at: https://sourceware.org/bugzilla/... which explains the __gcc_ISR N macros.

I outlined them, and pointed with links to the old discussions.  Yes, there are places for ASM in an AVR8 app.  Yes, they can be important to the app.  Yes, GCC does a marvelous optimizing job with complex stuff.  Yes, GCC has lost a lot of weight and the ISRs are much skinnier.

So far, the Q.E.D. examples given in the thread are all of the obese ISRs in GCC.  Many of the others have to do with reserving registers.  So if you change the title to reflect not "C language" but rather "with GCC's version of the C language for AVR targets", then I can sit quietly in the corner.

Now, regarding GCC's optimizer and handling of complex code:  I've thought about this some years back, after having written reams of production AVR8 code.   I'd say most are complex and detailed apps, with lots of stuff (ADC, comms, sensors, output devices, displays, ...) crammed into the chip.

But looking at my code itself, it isn't complex.  Nearly all is pretty straightforward.  Most ISRs will fit on a screen.  Data structures are quite simple (after all, how complex can you jam into an AVR8-class chip even the bigger ones?), so no real problems requiring the optimizing compiler to simplify a page-long expression.

Yes, if I would have had the ISR bloat outlined by some of the complaintants above I would have been a campaigner for machine language ISRs as well.

What C compiler are you using that does not show the generated code?  Every one I have used does just that!

I think the point is that you don't know it in advance - you have to go looking for it after the fact.

MOST of the time what you don't know doesn't hurt.  Oh it is swapping 2 bytes that it doesn't need to & my hot water calculation is then taking an extra 200ns.

So you live a bit dumb, happy, and generally satisfied...works out most of the time. 

On the other hand, lose a bit here, then lose some more over there, and some over here & you wonder why your graphics 3d game update seems "sluggish".     

Keeping counter in registers would make using a library difficult.

Certain things seems so easy to understand, after you get the idea.

One of the most complicated things that took some my time explaining to a girlfriend that became system analyst, was convince her that "the data containing in a certain memory address, could also be an address for another data"... 

If you think in assembly it becomes more simpler.

Each register is a small cup in the kitchen counter, it can hold any cooking ingredient, spices, liquid, grains, etc.

For the ingredientes that you use more frequently, like flour, salt, sugar, oil, you could reserve some cups, even write those names in the cup.

The advantage to do that (reserve cups) is that you don't need to wash and clean them after every use.

The flour cup can still have flour at its bottom, you can pour more flower without risking anything.

For other ingredients less used, you could in fact wash and dry the cup after every use, you don't know what you can use the cup next.

Reserving cups for often used ingredients means exactly that, you can not use them for any other ingredients, and, if necessary to use them (by lack of free cups) you will need to wash clean before the new use and wash clean after the use, even restoring the name "flour" on its tag.

C will reserve certain registers for more frequent use, in fact, to speed up the process, but it will NOT reserve all the registers, since other processes and routines can and will want to have free registers for their own use.

What means "free registers"?   A "free cup" means that the cook can get a clean cup, without any tag name, and start to use it during the omelet preparation, mixing and stirring eggs, he can do that for half an hour, knowing that particular cup is messed up with eggs, but will only use for eggs anyway.  At the end of the omelet, he will wash and clean such cup and return along to other "free cups".   Also, a "free cup" is known that anytime during the lunch preparation, that cup will never be necessary by the reserved cups, like flour, salt, etc, those were already tagged as exclusive.  A free is really that, free, you can use without messing up with the reserved ones, but it is your responsibility to keep account of that, a free register is free until you take over and use it for something else, you can not use the same free register for two independent routines without paying attention.   Being free doesn't mean the cook can mix eggs and the next minute use the same eggs dirty cup to prepare spices without cleaning it first.

In assembly language, before you start to write the code, you think about what will be the most used variables or pointers in your code, and "reserve" such registers for only that use, saving push and pull from stack, saving clock cycles.

It is very common in assembly to name certain registers as "TEMP", "TEMP1", etc... they have no specific function and can be used at anytime, anywhere, with exceptions.

They have very short life, for example in a counter that use few code lines, you will be quite sure that you WILL NOT use TEMP register in a long routine that can hold the value into the register for many instructions.  But you know that such TEMP registers should be free when entering a routine, and should carry nothing on exit, just "temporary" use.   The exception is when an interruption happens, if such TEMP register will be used in the interruption routine, it must be pushed on entry and pulled on exit.

Also, upon running the assembler, it can create a list of registers used in the code, even saying where they were used.  You can use that to improve your code.  A register that has massive use MUST be reserved, and maybe analyzed to see if the code is not wasting cycles saving such register among routines, sometimes is smart to spread its use to other registers with less use.

In C the compiler TENDS to be smart and optimize those things, but it is not perfect.

Because how C create variables, it tends to create them in RAM and use registers just during the processing time of such variables.

I use to see C pushing a bunch of registers, loading variables from RAM into such registers, run the routine, then store the registers back to RAM, pulling the original register values from stack.

In several of my assembly programs, I don't use RAM to store variables, they are all in registers.

Ask me why my codes are fast and small.  Of course, not large codes with hundreds of variables. 

Every time a register is saved on stack, there goes 4 clock cycles to trash.  Not counting the new data being loaded to such register and at the end such value send somewhere else.

If counting all of this, a minimum of 8 clock cycles per register;

PUSH  R18

LDS  R18, FOOVAR

...

STS FOOVAR R18

POP R18

If FOOVAR could be fixed on a reserved R18, it is there all the time, just use, will not need to waste 8 cycles, but nothing else can use such cup dirty with flour.

This is why AVR has 32 registers, a bunch of code can be written without using RAM.