AVR Freaks

Here we go again. Please tell me how, exactly, an AVR "knows" whether an ISR is written in ASM, how the AVR "knows" whether an ISR is written in C, and why or how it gets to the ISR faster if written in ASM. Of course, the answer is that the AVR does not know, and you get to the first instruction of the ISR just as fast no matter what language is used.

Now, let us repeat the above reasoning with >>leaving<< the ISR and returning to the mainline code. Eventually the RETI will be done and that takes the same amount of time regardless of the source language.

So, addressing the OPs question, "can GCC service interrupts fast". There is nothing inherent in C programming that would let interrupts be serviced more slowly than in ASM. That said, whether GCC's interurpt handling is as efficient as CodeVision or ImageCraft or Rowley may be another topic of discussion. Perhaps it does a fine job; perhaps you get what you paid for.

The same line of reasoning I used above can apply to the bodies of the ISRs. As always in these challenges, post the fragment of machine language or the algorithm that needs to be done. In almost all cases (the notable exceptions are those in which rotation or the concept of "carry" make the algorithm more efficient--C has no concept of those) straight C can match the ASM times.

Lee

Yes, often.

Not necessarily. Of course, it depends on the specific example. Most of my all-C applications use a few dozen bytes of stack, if that. I don't use many local variables. Why would ASM need "lower number of variables"--there is no reason based on the language; it depends on how you write it.

Yes, it is indeed a Holy War. But the question is not yet answered--show me a piece of code that is so much more efficient in ASM that it makes a difference.

There are some easy ways to demonstrate this. I already mentioned two of them: register rotation and use of the carry flag. Another might be 24-bit arithmetic--if it REALLY has an advantage in your app, then it is not convenient to do it in C where only 8, 16, and 32 bit integer types are provided.

I will close by hunting up two of my ISR examples I posted in recent threads on ISR construction. The first is a single-instruction ISR body. The other is a 16-bit x4 quadrature ISR.

There is very little fat in these ISRs. Yes, as I previously discussed, I chose my constructs carefully, and used global register variables--the same way it would be done in crafting a critical ISR in ASM. the above two examples are straight C using my choice of compiler that gives me the flexibility to think in machine language and write in C. I always enjoy challenging the generalized statements such as "It's true that it's faster ... ". Is it?

Lee

You're still missing the point! :roll:

It's not the language that you choose that makes the big difference to the performance of the code that you write - it's how you write it that makes the difference.

It is very likely that assembler code thrown together by a raw newbie with no previous assembler experience and no understanding of the processor architecture will be less efficient than 'C' code carefully written by an experienced embedded programmer with a thorough understanding of the tools and the target architecture!

Again, the point is: it's not the language that counts; it's how you use it.

If you write 'C' with no regard for the underlying architecture, and no understanding of the "cost" of the various constructs that you use, then you will obviously not end up with optimum code

As has already been noted, there are a few cases where 'C' just not suitable and assembler is the only sensible choice - but that's a matter of picking the right tool for the job, not a blanket generalisation like "C is slow; ASM is fast."

And I will say that critical parts can usually/oftem/mostly be done as fast as it gets...

...so you check the instructions, just as you look over the critical sections of your ASM program to see if it can be done better. I have worked in my life with several ASM/machine language gurus that will almost always use the optimal sequence the first time. These people are few and far between. You may very well be one of them.

There are multiple parts to this "challenge". The first is as I mentioned: the generaltities just are not true. Another part is the challenge to see if my tool of choice can generate tight code. So I look forward to seeing the example of the ISR that is sooooo much slower or larger in C. There certainly are some--I've got a couple driving Mega169 LCD segments that the board designer hooked up for ease of board layout, not for software. A single 7-segment digit is spread among 3 I/O bytes. I very quickly decided to write that in ASM. These examples are fairly widely separated, though

So I'm still waiting for the example that I can hold up and say "this ISR cannot be done nearly this fast in C".

Lee

Exactly.

Now, CodeVision has added some "smart ISR" checking and only saves what needs to be saved. That is the "think" part--you need to know the model of the way the compiler generated code.

The GCC model may be different, and the close-enough-to-optimal fragments that I posted may not apply to your compiler.

Now, if you call a function from your ISR, then pretty much all bets are off--the compiler is forced to save all working registers; it usually will not be able to determine what happens in that other fucntion, whether it is also called from mainline, etc.

I have talked myself out of doing that on all of my AVR apps to-date. I keep [almost] all of my ISRs as short as practical--typically a few microseconds. When sketching out the overhead needed to allow another nested interrupt through, it seems that the overhead of additional saving and restoring, the extra stack space needed, the protection against stack windup (as you mentioned), and extra interlocking means that I can get out of the low-priority ISR faster than the overhead to set up for a nested one. IMO the result (with non-nested ISRs) is a simpler and more reliable system. YMMV.

Lee

INTERRUPTS can interrupt themselves, and other INTERRUPT ISRs. SIGNAL ISRs cannot be interrupted and must complete before other SIGNALS or INTERRUPTS - and can interrupt INTERRUPT attributed ISRs.

- Dean :twisted: