[NSWI004] static inline

Petr Tuma petr.tuma at d3s.mff.cuni.cz
Fri Nov 20 06:43:14 CET 2020


Hi,

GCC seems to emit decent code for basic __atomic builtins that does LL/SC for you so maybe you do not even need to touch LL/SC yourself.

If you still want to, then you should use the GCC support for passing arguments between the assembly code and the surrounding C (https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html).

It is generally not safe to rely on register content being "left over" in registers, the only situation where you can be sure C will not interfere is if you write the function entirely in assembly (including the prologue and epilogue), but then the function will be in a different module and likely not inlined (unless GCC got better at IPO than last time I checked, which is quite possible :-).

Petr


On 20/11/2020 06:27, Kryštof Višňák wrote:
> Sorry for necroing this thread but would like to ask a related question.
> Is it ok to use assembly in inlined functions (sometimes the
> compiler inlines even functions that do not have the inline keyword
> strapped to them)?
> 
> Specifically, can I safely assume that the $a0 register holds
> the first parameter? I bumped into this problem when trying to write
> a wrapper function around ll/sc instructions. It seems to be working fine
> but may not be best practice.
> 
> Thanks in advance
> KV
> 
> út 10. 11. 2020 v 14:55 odesílatel Lubomír Bulej <bulej at d3s.mff.cuni.cz> napsal:
>>
>> Hi,
>>
>> TLDR: they are normal functions, except they are very likely to be inlined.
>>
>>
>> Each of the modifiers tells the compiler something about the function.
>>
>> "static" tells the compiler that the function is private to the compilation
>> unit, i.e., it cannot be called from outside the file it is used to.
>>
>> "inline" is a hint for the compiler suggesting to inline the function when
>> called. That keyword is relatively old and as compiler technology advanced,
>> the compilers were typically able to make better decisions about whether to
>> inline a function or not, especially for functions that are "public", i.e.,
>> exported. Modern compilers are therefore likely to ignore the hint on
>> non-static functions.
>>
>> When used together, "static inline" tells the compiler that a function is
>> local to a compilation unit (i.e., cannot be called from outside) and that it
>> would be nice to inline it, which the compilers (even modern ones) are much
>> more likely to respect. The function then effectively becomes a snippet of
>> code that can be inlined whenever needed.
>>
>> This allows removing function call overhead for functions that just hide
>> implementation details, but are otherwise so short that the function call
>> overhead would be comparable to what the function is actually doing.
>>
>> For example, in the case of the list implementation, many of the operations
>> just rewire pointers, so they compile to a few (small units) instructions.
>>
>> This is one of the few cases (at least in C) in which code is allowed to live
>> in a header file, because it is meant to provide a private copy of the code to
>> any source file that uses it. The compiler throws away the unused functions
>> (they are all static), and inlines those that are used, thanks to the "static
>> inline" hint combined with small size of those functions.
>>
>>
>>
>> Best regards,
>> Lubomir
>>
>>
>> On 10/11/2020 13:11, Káně, Vojtěch wrote:
>>> Hello,
>>> I would like to ask what exactly static inline functions are. They are used in
>>> include/adt/list.h for example. I did some research on my own, but all the
>>> answers were mixing ANSI C, GNU C and C++ together so I got confused even more.
>>>
>>> I am asking just out of curiosity, it is not blocking my implementation.
>>>
>>> Thank you in advance,
>>> Vojtěch Káně
>>>
>>
>> _______________________________________________
>> NSWI004 mailing list
>> NSWI004 at d3s.mff.cuni.cz
>> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
> _______________________________________________
> NSWI004 mailing list
> NSWI004 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
> 


More information about the NSWI004 mailing list