Function inlining in S32K RTD drivers

[strofald]

Hello,

I am using RTD drivers v5.0.0.

I noticed that in several points of the source code, there are function declared as 'static inline'.

However, I am using the IAR compiler with forced compiler options that by default disable the native inlining, so a declaration like this:

static inline foo (void)

will not be treated as inline by the compiler.
To overcome this, in my AUTOSAR BSW code I have set some compiler abstractions, so that every module of the AUTOSAR BSW stack uses inlining only by using the define LOCAL_INLINE. 
This define LOCAL_INLINE is then resolved as:

define LOCAL_INLINE static inline __attribute__((always_inline))

and in this way the modules of the AUTOSAR BSW stack can successfully use the inlining as foreseen by the compiler.
Anyway, I saw that the S32k3 RTD drivers that I am using do not seem to be using the Compiler abstraction keywords (LOCAL_INLINE, FUNC, etc) and therefore I am not be able to use the inlining correctly.

Is this an issue in those drivers or am I missing something?

Thanks

Kind regards,

Aldo

[strofald]

Hello,

sorry but your response is not very clear to me.
I understand that I can replicate the compiler options used by NXP, but that it not a solution for us since we cannot change them, and also this is not what AUTOSAR states in the Specification of Compiler Abstraction: I should not be 'forced' to use specific compiler options to make inlining work, but instead through the use of the Compiler Abstraction I can tune the behavior specifying the needed attributes based on the compiler I am using, of course given that the functions are actually __using__ the macros at all.
As I stated above, from what I can see from the source code of the MCALs, there are functions that are not declared by using the compiler abstraction macros like INLINE or LOCAL_INLINE, for example:

strofald_0-1755671824971.png

since they don't use the INLINE or LOCAL_INLINE macros, I cannot use my Compiler.h abstractions.

This seems like an issue in the MCAL drivers, I can tell you that I saw other MCAL module from other silicon vendors and they actually use those macros as stated by AUTOSAR standard.
Is there the possibility of reporting this issue so that it can be fixed in the upcoming releases?
Thanks

[Julián_AragónM]

Hi @strofald,

Let me ask the SW team about this issue. But it seems like the snippets you are referring are based on the non-AUTOSAR (IP) layer, which I believe is not constraint by SWS and often uses static inline for performance and portability across compilers.

I will get back with you as soon as I get an answer.

Best regards,
Julián

[strofald]

I understand that, but you can also find snippets of code that are missing the usage of AUTOSAR keywords in the main module sources; here is just an example for the Adc.c file:

strofald_0-1755768933351.png

I understand your point, but please consider also our point of view: in the case you described we would not be able to use the benefits of the inlining and this could cause potential performance issues.

Aldo

[Julián_AragónM]

Hi @strofald

I understand your point. Let me submit a ticket with the dedicated RTD team to see what their response is.

Best regards,
Julián

[Julián_AragónM]

Hi @strofald,

The same MCAL functions as delivered to customer with the corresponding INLINE or LOCAL_INLINE macros were tested with Green Hills, IAR, Diab and GCC. If you want to replicate NXP compiler settings, these are mentioned in the release notes (2.7.4 IAR Compiler/Linker/Assembler Options).

The behavior is compiler specific. The INLINE and LOCAL_INLINE macros translate into compiler specific commands, which are found in Compiler.h. For example, for GCC, these macros translate as next:

#define INLINE             inline __attribute__((always_inline))
#define LOCAL_INLINE       static inline __attribute__((always_inline))‍‍

And GCC compiler manual describes "always_inline" attribute as next:

Julin_AragnM_1-1755627438715.png

So basically, refer to Compiler.h and from there; compiler specific documentation and compiler settings. 

Best regards,
Julián