On 05/09/12 18:46, Jeff Kenton wrote:
On 09/05/2012 12:36 PM, David Brown wrote:
On 05/09/12 07:37, Ian Lance Taylor wrote:
On Tue, Sep 4, 2012 at 10:35 PM, Xin Tong<xerox.time.tech@xxxxxxxxx>
wrote:
any reason why naked functions are not support for x86 ?
No special reason, no.
Ian
Is this something that could easily be moved from target-specific
attributes into more general gcc support? I'm sure the maintainers of
ports like the avr that have a "naked" attribute would be happier if
it were a general feature rather than specific to their port, and I'm
sure that other embedded targets would appreciate it.
However, I have no clue as to whether this is a simple matter of
moving code from a target-specific file to a generic file, or if it
needs a lot more work.
David
It's not clear (to me) what the original poster was looking for. If he
just wants to eliminate (or minimize) the prologue and epilogue code he
can sometimes get that effect for simple leaf functions by increasing
the optimization to -O3. But I don't know for sure if that is what he
was asking.
I can't answer for the original poster, but there are a few uses of
"naked" functions in embedded systems. One is if you have some sort of
RTOS (real-time operating system, in case you are unfamiliar with this
sort of programming). The task switching mechanism already saves all
the registers, so you don't want the called "main" function for a thread
to save them again. If you are used to x86 programming on a PC, you
might wonder why someone would fuss about saving 4 registers when you
have 4 GB of ram - but it's a different matter if you have a small ARM
microcontroller with 32 32-bit registers and 10 KB of ram, where you can
save close to 1% of your ram space with "naked".
Another case is if you have interrupt functions in which the low-level
handling is done in assembly - perhaps outside entirely outside the
function, or perhaps as inline assembly as the prologue and epilogue to
the functions.
"naked" functions are also very convenient as a place to put pure
assembly code - either assembly-only functions, or "non-function"
assembly code. Personally, I prefer to use gcc's inline assembly syntax
for such code rather than writing a stand-alone assembly module, and
sometimes the compiler can use the extra knowledge for optimisation.
I think "x86" is probably the target where there would be least call for
these uses, but maybe I'm wrong there.
