| Author |
Message |
|
|
 Posted: Mar 17, 2010 - 10:42 PM |
|
Joined: Jul 23, 2001
Posts: 975
Location: Osnabrueck, Germany
|
|
|
hooverphonique wrote:
and that still means that they need to be saved in non-isr context if they are in use when calling the function, and that seems like a waste of space compared to the called function just saving the registers it trashes instead of saving the whole range..
Why "whole range"? In the non-isr context the caller knows which of these registers are in use and need to be preserved over the call. The called function doesn't know this. So always saving/restoring these registers in the called function would be a waste of space and time. |
_________________
Stefan Ernst
|
| |
|
|
|
|
|
|
Posted: Mar 17, 2010 - 10:42 PM |
|
Joined: Aug 29, 2008
Posts: 84
Location: Denmark
|
|
|
sternst wrote:
hooverphonique wrote:
that only makes sense if there is a range of registers that a function can use without saving them (ie the compiler expects them to be possibly trahed)
You haven't read my post, have you?
No, I hadn't, sorry.. I clicked directly on the "last post" icon and it was Cliff's post.. but it all makes sense now, even though I still think that having a considerable amount of regs that a function doesn't need to save seems like a cause of bloat.. anyway, that's a completely different discussion  |
|
|
| |
|
|
|
|
|
|
Posted: Mar 17, 2010 - 11:16 PM |
|
Joined: Jul 18, 2005
Posts: 33138
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
seems like a cause of bloat..
Yes but the whole point of my first post on this subject that with a little help you can help the compiler avoid generating such bloat and that the wise programmer will be aware of this and what's going on behind the scenes.
Too often we see threads here where someone is trying to do something very time constrained in an ISR and cannot get their brain around where 20-30 cycles have suddenly disappeared to. If they check the generated Asm the wasted cycles become obvious and if they then realise that either (a) avoid calls in ISRs or (b) at least help the compiler if calls will be made will reduce the cycle bloat they'd be much happier bunnies. |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 17, 2010 - 11:32 PM |
|
Joined: Aug 29, 2008
Posts: 84
Location: Denmark
|
|
Yes, of course.. and this is all important info.. I've often looked at the generated assembly and wondered why the compiler did what it did, generating unnecessary code, etc...
I guess this, unfortunately, means that using an external handler function for taking care of an isr where the specific interrupt vector is unknown by the handler is a bad idea (i.e. the handler is generic in the sense that it knows how to handle e.g. a counter overflow, but it doesn't know which specific counter is used, but that can be fixed by using specific inlining). |
|
|
| |
|
|
|
|
|
|
Posted: Mar 17, 2010 - 11:38 PM |
|
Joined: Jul 18, 2005
Posts: 33138
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I guess this, unfortunately, means that using an external handler function for taking care of an isr where the specific interrupt vector is unknown by the handler is a bad idea
You mean calling through a variable function pointer?
In that case, yes, the compiler doesn't have a hope at compile time of know what the called routine might be so is bound to generate the littany of PUSH/POPs
(it's just vaguely possible that if everything were in the one .c file that maybe the compiler could see the complete picture and avoid some waste/bloat - but I doubt it - you'd need to run some experiments and examine the .lss) |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 17, 2010 - 11:41 PM |
|
Joined: Aug 29, 2008
Posts: 84
Location: Denmark
|
|
| no, no function pointer, but a handler function in another compilation unit.. but I guess the result would be the same.. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 17, 2010 - 11:42 PM |
|
Joined: Feb 23, 2005
Posts: 84
Location: Salt Lake City, Utah
|
|
|
hooverphonique wrote:
Yes, of course.. and this is all important info.. I've often looked at the generated assembly and wondered why the compiler did what it did, generating unnecessary code, etc...
The thing is, it's not unnecessary. It's actually VERY necessary for the program to work correctly. |
_________________
I have too many hobbies.
TruGolf.com
|
| |
|
|
|
|
|
|
Posted: Mar 17, 2010 - 11:48 PM |
|
Joined: Aug 29, 2008
Posts: 84
Location: Denmark
|
|
|
mhatter wrote:
hooverphonique wrote:
Yes, of course.. and this is all important info.. I've often looked at the generated assembly and wondered why the compiler did what it did, generating unnecessary code, etc...
The thing is, it's not unnecessary. It's actually VERY necessary for the program to work correctly.
Maybe i wasn't clear on what I was talking about there.. It was not meant in the context of saving/restoring registers |
|
|
| |
|
|
|
|
|
|
Posted: Mar 18, 2010 - 04:41 PM |
|
Joined: Oct 29, 2006
Posts: 1396
|
|
|
clawson wrote:
Quote:
I guess this, unfortunately, means that using an external handler function for taking care of an isr where the specific interrupt vector is unknown by the handler is a bad idea
You mean calling through a variable function pointer?
In that case, yes, the compiler doesn't have a hope at compile time of know what the called routine might be so is bound to generate the littany of PUSH/POPs
The compiler could be certain if it looked at the attributes of an ISR-like function.
It wouldn't have to save any registers,
though it might want to put a CLI after the call.
Quote:
(it's just vaguely possible that if everything were in the one .c file that maybe the compiler could see the complete picture and avoid some waste/bloat - but I doubt it - you'd need to run some experiments and examine the .lss)
|
_________________
Michael Hennebry
"I can't tell you where the contract was designed,
but be careful because it's still hot." -- Dogbert
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
