This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merging gdc (GNU D Compiler) into gcc

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


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]