Re: Merging gdc (GNU D Compiler) into gcc

[David Brown <david at westcontrol dot com>]

On 04/10/2011 23:47, Andrew Pinski wrote:
> On Tue, Oct 4, 2011 at 2:40 PM, David Brown<david.brown@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