# \_\_inline, ARM7 and IAR compiler

**URL:** <https://forums.freertos.org/t/inline-arm7-and-iar-compiler/4080>\
**Category:** Kernel\
**Created:** [December 11, 2007, 11:31am UTC](https://forums.freertos.org/t/inline-arm7-and-iar-compiler/4080 "2007-12-11T11:31:22Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 11, 2007, 11:31am UTC](https://forums.freertos.org/t/inline-arm7-and-iar-compiler/4080/1 "2007-12-11T11:31:22Z")

</div>

**[mikej42](https://sourceforge.net/u/mikej42/)** wrote on [Tuesday, December 11, 2007](https://sourceforge.net/p/freertos/discussion/382005/thread/b179b745/#ccb9):

Hello All

I am using the IAR ewarm (4.42a) with freeRTOS 4.5.0 at present, and am looking into using some \_\_inline functions.

I find that portmacro.h for the IAR compiler and at91sam7s includes #define inline in Compiler specifics, so that I still don’t get inlining even with #define \_\_inline inline added.

If I comment out the #define in portmacros.h the compiler objects to two basic functions:vTaskSwitchContext and vTaskIncrementSwitch, both apparently because they are declared as \_\_inline in the header file, and defined in the source file the same way, which the IAR compiler doesn’t seem able to cope with.

To keep rolling on I have commented out the \_\_inline tags, but this doesn’t seem the correct way forward.

Do these functions need to be \_\_inline? Is inlining significant in gaining speed of operation?

Any thoughts welcomed

Mike Newsome

Hitek Power Ltd, England

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [December 11, 2007, 12:18pm UTC](https://forums.freertos.org/t/inline-arm7-and-iar-compiler/4080/2 "2007-12-11T12:18:20Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Tuesday, December 11, 2007](https://sourceforge.net/p/freertos/discussion/382005/thread/b179b745/#ccb9/713f):

The inline thing is a legacy from one of the first ports and is a PITA now.&nbsp; It should be removed.

The #define in portmacro.h is to prevent the problem you are finding when you comment it out.&nbsp; The order in which the include files are listed should be such that the #define does not effect other include files (it comes after), but will your own code.&nbsp; The library files provided by atmel make heavy use of inlines, but these should work correctly the way things are at the moment.

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [December 11, 2007, 1:39pm UTC](https://forums.freertos.org/t/inline-arm7-and-iar-compiler/4080/3 "2007-12-11T13:39:47Z")

</div>

**[mikej42](https://sourceforge.net/u/mikej42/)** wrote on [Tuesday, December 11, 2007](https://sourceforge.net/p/freertos/discussion/382005/thread/b179b745/#ccb9/713f/47ac):

Thanks, Richard

I wanted to make use if a bit of inlining for speed, and was starting to play around with it.

I have commented out the bits in question while I play, and will decide later!

While I understand the concept of in line code, it seems that IAR at least \_may\_ not inline it, and in this case would put a copy of the function in every module that calls it!

There is also a #pragma inline, but I feel the keyword is more useful - it can be #defined away!

Many thanks

Mike Newsome