RE: [avr-gcc-list] Stack use - possible bug

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Paulo Marques
> Sent: Wednesday, June 09, 2010 8:16 AM
> To: Dale
> Cc: address@hidden
> Subject: Re: [avr-gcc-list] Stack use - possible bug
> 
> Paulo Marques wrote:
> > Dale wrote:
> > 
> > The problem is that people running gcc on "big" machines 
> never notice
> > this. The other crowd that noticed it already was the linux kernel
> > people were the stack is limited to 4Kb. I'm trying to find 
> a similar
> > thread that I remember reading on LKML, but my google-fu is 
> letting me
> > down :(
> 
> Found it:
> 
> http://lkml.org/lkml/2008/8/26/197
> 

I agree with Paulo in that people running on big machines won't notice this or 
even really care.

I have to agree with Linus in that post on this:
"Gcc inlining is a total and utter pile of shit. And _that_ is the problem. 
I seriously think we shouldn't allow gcc to inline anything at all unless 
we tell it to. That's how it used to work, and quite frankly, that's how 
it _should_ work."

It's frustrating that GCC attempts to do any implicit inlining based on other 
criteria (marking a function static), or that the "inline" keyword is 
essentially soft (that it "may" inline it, but it "may not"), which then 
necessitates having (nonstandard) function attributes of "always_inline" and 
"noinline". All of this is based on heuristics that is probably not tuned 
correctly for the AVR. Typically if there are any heuristics in GCC for any 
feature, I can almost guarantee that they are not tuned correctly for the AVR. 
Ok, that's probably an overly-pessimistic statement, but hopefully one can 
understand the sentiment.

Unfortunately this is also why I will essentially ignore the issue as stated in 
the original post. It's not a bug, it's probably a missed optimization that 
will probably not get fixed for a long time, and the issue is easily solved by 
being much more explicit to the compiler as to what should be inlined and what 
should not be inlined because the compiler is not psychic and it has no idea 
what the programmer is intending to do with the program. There, I said it. 
There is much bigger fish to fry when it comes to fixing things in the 
compiler. We're talking about applications for a deeply embedded 8-bit system. 
There will always be some level of weirdness, and a much greater burden is 
always placed on the software engineer to be aware of these cases due to 
extreme hardware limitations and the engineering tradeoffs that ensue.

Eric