0

Can we use __forceinline type in Embedded programming through C11?

I tried with the following syntax for

__forceinline static void RamPost(void);

But end up getting the error naming- "this declaration has no storage class or type specifier"

Any idea where I'm wrong?

Thanks.

Lundin
  • 195,001
  • 40
  • 254
  • 396
Rahul Joshi
  • 11
  • 2
  • Does this answer your question? [(How) Can I inline a particular function call?](https://stackoverflow.com/questions/14571593/how-can-i-inline-a-particular-function-call) – fdermishin Jan 08 '21 at 11:02
  • Can you clarify, which compiler are you using exactly? – fdermishin Jan 08 '21 at 11:23

4 Answers4

3

Forced inlining in the embedded programming is a very handy tool. It is much safer than than macros (type checking, normal C syntax etc etc).

Most of the compilers have extensions to force inlining (or ban it).

  1. gcc family compilers (clang, icc ...)

in gcc the most common way is to use __attribute__((always_inline))

  1. Microsoft C++ compiler extension is __forceinline
  2. IAR : #pragma inline = forced
  3. Keil: __attribute__((always_inline)) and __forceinline
  4. GH: as far as I remember __attribute__((always_inline))
  5. Mplab XCx C compiler __attribute__((always_inline))
0___________
  • 60,014
  • 4
  • 34
  • 74
  • Thank you for the segregated compiler specific answer for using inline keyword . – Rahul Joshi Jan 08 '21 at 12:56
  • 1
    "It is much safer than than macros". Maybe. https://godbolt.org/z/xvcrh5 – Lundin Jan 08 '21 at 13:36
  • @Lundin macros are prone to many prblems like here: https://godbolt.org/z/sGWTz3 – 0___________ Jan 08 '21 at 13:50
  • 1
    Sure, macros _are_ of course flawed in many ways. But so are functions, C is far from a type safe language. It's not just a matter of reading compiler warnings, C has a tendency to merrily accept anything that can get boiled down to an `int`. For example the function in my example would also accept `char`, `short` and `long` etc and do so cleanly without any warnings. Same thing while feeding a signed negative number to a function expecting an unsigned number or vice versa. These problems could actually have been prevented with a type safe macro. – Lundin Jan 08 '21 at 14:01
  • The answer shows one reason why it is a bad idea - it gets complicated if you need your code to build for multiple targets and compilers. The solution is much worse then the problem - though the real problem is perhaps the _premature optimisation_ implied by thinking you can make better decisions about what and when to inline than the compiler. – Clifford Jan 08 '21 at 14:34
  • @Clifford in embedded world portability is not the main problem. – 0___________ Jan 08 '21 at 14:40
  • @P__JsupportswomeninPoland : You are teaching grandma to suck eggs. It is a broad domain - you do not speak for _all_ the _embedded world_. In 30 years of embedded development I have frequently reused code across projects and compilers. Even if not building cross-target code, often there is still a need to _port_ code (in the sense of modifying it for a specific platform), and the less of this sort of thing, the easier that task will be. I support this answer as nicely comprehensive BTW - the first line is however perhaps unnecessary comment/opinion that could have been omitted however. – Clifford Jan 08 '21 at 15:14
1

__forceinline is not standard C, so you can only rely on it if your compiler supports it.

The only fully portable way to force inlining is to use macros instead of functions. So instead of:

int add(int a, int b) { return a+b; }

you can write:

#define add(a,b) ((a)+(b))

However, this can make debugging much more complicated, and it's much easier to introduce bugs. So avoid it if possible.

klutt
  • 30,332
  • 17
  • 55
  • 95
  • £macros and inline functions have nothing in common except calling syntax. And this answer does not address the question. – 0___________ Jan 08 '21 at 11:57
  • @P__JsupportswomeninPoland Added a line for completeness. Macros have their drawbacks, but it can be a viable workaround for OP. – klutt Jan 08 '21 at 12:05
  • No - very error prone workaround. I rather advice to avoid function like macros at any price. – 0___________ Jan 08 '21 at 12:06
  • @P__JsupportswomeninPoland That's why I wrote *"However, this can make debugging much more complicated, and it's much easier to introduce bugs. So avoid it if possible."* – klutt Jan 08 '21 at 12:07
  • as of now Macro is not used for our requirement . Thanks though. – Rahul Joshi Jan 08 '21 at 12:58
0

__forceinline isn't standard C, but some compiler-specific non-standard extension (Keil?). The compiler is telling you just that - it doesn't know what the keyword does since it isn't valid C.

Generally, the compiler is much more capable than the programmer in determining what to inline, why the standard inline keyword is mostly an obsolete feature nowadays (just like register).

There's very few cases where you actually need to enforce inlining. For the rare case when you do, you should probably have done the inlining by hand, possibly in assembler, or perhaps through a function-like macro. Function-like macros are generally to be avoided, but they are less worse practice than non-standard keywords IMO.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • I agree to all but your assement of the usefulness of `inline` and `register`. In particular `inline` is a very valuable feature since it allows to have function definitions in header files that otherwise would result in multiple definitions in every translation unit that includes the header. – Jens Gustedt Jan 08 '21 at 11:17
  • `__forceinline` seems to be used by Microsoft and ARM compilers also – fdermishin Jan 08 '21 at 11:19
  • 1
    *"is mostly an obsolete feature"* - Especially since they have always only been recommendations. – klutt Jan 08 '21 at 11:20
  • @JensGustedt if actually does 'static' in this case. – 0___________ Jan 08 '21 at 12:16
  • `inlining by hand, possibly in assembler` @Lundin why? What is wrong (in the embedded world especially) with forced inlining when necessary? Hew did not ask about your opinion about the inlining, only about the code he did not understand. – 0___________ Jan 08 '21 at 12:17
  • 1
    @P__JsupportswomeninPoland Because forced inlining is kind of like ordering a pepperoni pizza without pepperoni. If you never want the function to be a function, then why did you make it that way? This in turn suggests problematic bigger picture issues in the program design. If the function you wish inlined is local to the same translation unit as the caller, then it will almost certainly get inlined if it makes sense to inline it. If it isn't local, then again there is something fishy with the overall program design. – Lundin Jan 08 '21 at 12:28
  • @Lundin To be fair, a VERY valid reason is that you want to avoid BOTH code duplication and unnecessary function calls. – klutt Jan 08 '21 at 12:43
  • @klutt Except if you call the function multiple times from all over the same translation unit, inlining might not be such a good idea after all, since that would bloat the executable size drastically. Which in turn is a very valid concern in embedded systems where flash is limited. – Lundin Jan 08 '21 at 12:48
  • @Lundin I would rather say that your answer and comments are your personal opinion not the technical answer. ***`This in turn suggests problematic bigger picture issues in the program design`***. Leave the project architecture to the actual programmers (but of course you know better what is good for them) and do not judge what is the problem or not. – 0___________ Jan 08 '21 at 12:57
  • @Lundin OP does not ask our opinion about inlining. You answer IMO is 100% off topic – 0___________ Jan 08 '21 at 12:59
  • @P__JsupportswomeninPoland That's not how engineering works. If I were a carpenter and a fellow carpenter asks me for the best way to drive in a screw with a hammer, then I'd tell them to consider a screwdriver instead. Rather than go suggesting different brands of hammers to them. – Lundin Jan 08 '21 at 13:04
  • @Lundin Yes, that's a thing to consider, but it does not make my point invalid. I'm just saying that valid use cases exist. – klutt Jan 08 '21 at 13:06
  • @P__JsupportswomeninPoland Relax a little bit. Just because OP has not asked for opinions about inlining does not make it a bad idea to explain a bit about them. That can be useful for both OP and future readers. And the fact that OP didn't state something like "I know about the drawbacks" is an indicator that OP is not aware of them. – klutt Jan 08 '21 at 13:08
  • ***`different brands of hammers to them`***. No comment .... Ask compiler designers to remove those extensions. – 0___________ Jan 08 '21 at 13:20
0

The __ prefix indicates that it is a compiler specific keyword and not standard C. Consult your compiler documentation. It will most likely have a means of forcing inline through compiler switch, #pragma or __attribute__ or it may simply guarantee to inline anything marked inline.

Clifford
  • 88,407
  • 13
  • 85
  • 165