On 04/10/2011 23:47, Andrew Pinski wrote:
On Tue, Oct 4, 2011 at 2:40 PM, David Brown<david.br...@hesbynett.no> wrote:
"naked" functions are often useful in embedded systems, and are therefore
useful (and implemented) on many gcc targets. It would make sense to have
the attribute available universally in gcc, if that doesn't involve a lot of
extra work, even though it is of little use on "big" systems (Linux,
Windows, etc.).
Is it really useful if you can have a small top-level inline-asm wrapper?
The "naked" attribute is used precisely when you don't want any wrapper
or other code that you don't absolutely need.
An example of use is when you want to write the prologue and epilogue
manually - perhaps the compiler's standard interrupt function prologue
and epilogue are not quite good enough for a special case, so you write
your own inline assembly. You don't want the compiler to generate
additional register saves, frame manipulation, etc.
Some toolchains are configured to have a series of "init" sections at
startup (technically, that's a matter of the default linker scripts and
libraries rather than the compiler). You can get code to run at
specific times during startup by placing the instructions directly
within these sections - but it must be "raw" instructions, not function
definitions (and definitely no "return" statement). The stack may not
be defined at this stage - perhaps you are using such code to initialise
the memory system or do other low-level setup. For an example, see this
link:
<http://www.nongnu.org/avr-libc/user-manual/mem_sections.html>
I've also used "naked" functions to provide a place to store specific
assembly code - I prefer to use inline assembly in C rather than a
separate assembly module.
RTOS'es often use "naked" in connection with tasks and task switching.
After the RTOS has gone to all the effort of saving the registers and
task context, it needs to jump into the next task without there being
more overhead of stored registers. On small RISC microcontrollers, it's
possible for the register bank to be a significant proportion of the
size of the chip's ram - you don't want to waste the space or the time
saving things unnecessarily.
Using the "naked" attribute means a little more of such code can be
written in C, and a little less needs to be written in assembly. That's
a good thing. And making "naked" consistent across more gcc ports means
a little more of such code can be cross-target portable, which is also a
good thing. You are never going to eliminate all target-specific parts
of such code, nor can you eliminate all assembly - but "naked" is a step
in that direction.
While I'm on the subject, it would be /very/ nice if the gcc port
maintainers agreed on function (and data) attributes. Clearly there
will be some variation between target ports, but surely it would be
easier to write, port and maintain if there were more consistency. From
a user's viewpoint, it is hard to understand why some targets use
"long_call" attributes and others use "longcall" to do the same thing,
or why there are a dozen different ways to declare an interrupt function
on different architectures. If these can be combined, it would be less
effort for the port maintainers, easier for users, and less
documentation. It might also make it easier for useful attributes (like
"naked", or "critical") to spread to other target ports.
mvh.,
David
