Code that is part of the core tree used for everything should adhere to the following rules
This is not supported by all the compilers we use.
The floating point support varies by platform and even when present is often very slow on a small micro, and adds a lot of code.
On several platforms this sucks in large non re-entrant support routines tha would require saving more state on a context switch
cc65 can't handle large stack offsets, and on Z80, 8085 and 6800 series processors there is much great expense accessing beyond the 128 or 256 byte range around the stack frame.
This is the worst case for the compilers used.
Not all compilers support them.
Several compilers generate shorter and cleaner initialization code on function entry if local variables are initialized in their declaration and the initializers are together.
There are limited indexing registers on some targets so generating a series of references to one pointer is far better than working with several. The kernel tries to cluster things into arrays of structs with all the properties for this reason.
while (x < n + 2 * p) { func(); }
often requires the math is evaluated each time. On a modern processor nobody notices. On an 8080 you do.
C has some annoying rules about type promotion and arithmetic which mean that on certain systems uint8_t is actually expensive. On such systems uint_fast8_t will be a faster unsigned type.
Sign extension is really expensive on some processors. The 8080 also lacks signed comparisons making signed operations more expensive.
Currently the code mostly uses a Linux like style but with a confusion of 4 and 8 character indenting. This should be moved to 8 character indenting for core code. Reformatting is being done gradually when appropriate.
The kernel uses a few extra type defines of its own.
Tag an array as packed. On many systems this is the natural order of things and they don't support any "packing" attribute. On gcc based targets it expands to the expected attribute notation.
A store/load barrier. On many of the ports this is actually a no-op because the compiler isn't smart enough to move load/stores over a statement boundary.
Mark a function as inlineable if supported by the compiler
On certain targets single argument functions have a special calling pattern, especially with calls to assembly code. This is used to mark such functions. Generally speaking the use of __fastcall is only done for platform specific uses.
Marks a variable that can be turned into a static for performance on processors that benefit from not having too many local variables to juggle at once. This notably affects Z80 - use with care. Various general purpose values used in syscalls are instead referenced via the udata for the same effect but without re-entrancy problems.
Mark a variable that is used a lot (more than about 8 times) in a function as a pointer. This is used to help the 6502 compiler as the other compilers generally either do registerisation on their own or don't do it at all.
Tell the compiler that x is actually used and silence any warnings that it is not referenced.
This should be self consistent but the constraints on the core code do not apply. Things like compiler extensions can be freely used, along with other types and features.
Target specific code that isn't maintained actively by a contributor is a candidate for reformatting, particularly if the style is strange. Target code that is actively changing is not.
Generally imported code keeps the style it had originally unless that style is sufficiently weird to be a problem (eg the Bourne Shell), or conflicts wiht the constraints of the tool chain for a platform using it.