https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85709

            Bug ID: 85709
           Summary: Consistent variable, type and function attributes
                    across ports
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at westcontrol dot com
  Target Milestone: ---

gcc supports many different targets.  For some of these, there can be special
attributes (variable, type, function) for particular features.  This is
important to programming low-level and bare-metal code.  Often these are for
particular features of the particular architecture, and that's fine.

However, they can also be more general attributes that might be of interest or
use across a range of ports.  There are also cases where different ports have
attributes for the same feature, but are inconsistent about naming or other
details.

Would it be possible to tidy this up a little, giving more features and greater
consistency for people who work with multiple gcc targets?

Examples of attributes that could be generalised and used on many ports :

"naked" function attribute, for SPU, RISC-V, MSP430, AVR, and a few others.

"critical" function attribute for MSP430, which disables global interrupts
during the function.  (Clearly this is not appropriate for all targets - but it
would be useful on many more devices than just the MSP430.)

"noinit" variable attribute for MSP430 that puts the variable in a different
section (not .bss) which is not cleared at startup.  This can improve startup
times when you have large static arrays, and lets you keep data across resets. 
It would be useful on many microcontrollers and small systems.  


Examples of inconsistent attributes :

"interrupt" function attributes handled in different ways in different ports,
with different naming and details.

Function attributes to explicitly save all volatile registers (useful for
functions called from assembly or interrupt handlers), or to say that no
registers need to be saved (useful for RTOS thread task functions) - some ports
have these, with different names, but they are inconsistent and could be useful
on many targets.

Reply via email to