C Gauges & Inline Functions

[n4gix 4,947]

I was wondering if it is possible to declare a function (callback) to be "inline" within a C gauge, and if so... is there any speed benefit to doing so?I know, I could TRY it myself, but I was wondering if anyone had already checked to see if it will be beneficial... :)

[Guest christian]

inline is a C++ keyword, so if you have your compiler set to compile pure C code, it won't compile. The way around it is to use #define, which MS uses extensively. #define has the drawback that it doesn't get parsed (and checked) by the compiler, but the pre-compiler. MS has added it's own deviation from ANSI C called __inline. This is the best solution, and MS uses it (but you need to enable MS extensions, your code won't be portable, but since it's very unlikely you'll port it to a different platform anyway, this shouldn't be a problem).In regards to the callback functions, it won't work. If you declare a function as inline, the compiler will still decide whether to inline it. Since the callbacks are declared as function addresses in a struct, the compiler simply can't inline the function. We don't have access to the underlying code (it's compiled in a dll). The whole point of the callbacks is that we get a function address we can add code to.In summary, you can (and should) use __inline if you declare your own common (simple) functions, e.g. to convert units. For callback functions, your compiler can't inline them, since the gauge interface is already in compiled dll form.I hope this makes sense.Cheers, Christian

[n4gix 4,947]

>inline is a C++ keyword, so if you have your compiler set to>compile pure C code, it won't compile. I use MS Visual C++ .Net v8.0 (I am using the v8.0 beta compiler).>In regards to the callback functions, it won't work. If you>declare a function as inline, the compiler will still decide>whether to inline it. Since the callbacks are declared as>function addresses in a struct, the compiler simply can't>inline the function. We don't have access to the underlying>code (it's compiled in a dll). The whole point of the>callbacks is that we get a function address we can add code>to.Thanks for clearing that up. So the compiler would simply expand the inline function out of line... making the whole exercise pointless. :)>In summary, you can (and should) use __inline if you declare>your own common (simple) functions, e.g. to convert units. For>callback functions, your compiler can't inline them, since the>gauge interface is already in compiled dll form.That won't happen too often, since most of the conversions are readily available in the "Arne Bartels Enhanced fs9gauges.h" file... :)I was just wondering (since I'm a complete neophyte in C++) whether it would speed up the gauge by not having to constantly clear & reload the instruction cache...

[wsieffert 0]

I wonder if Arne or Dai is going to update the FS9gauges.h for the SD2GAU17.ZIP for the errors you found?W. Sieffert

[Guest zip]

Inlining code, going back to assembler days, is just a method to have the compiler generate duplicate instructions wherever it sees a function marked with inline (keyword, directive, whatever).The benefits are that you avoid 1) pushing params on the stack2) possible stack overflow code verification (added by the compiler for you unless you turned that off)3) a jump / return loopNo particular advantage from a clarity standpoint since the code still looks like a function.Speed-wise, you still run the body of the function, so there are no savings there. However, you do save in terms of the call/return and stack population/check. It gets more expensive if you cross modules or you force a context switch on the CPU. But, for functions on the same thread, you're only talking a few cycles so not a whole lot of impact on the FPS on the average CPU. Conversions and one line type functions are a good candidate for inline functions because you basically have very few statements generated, so there is little impact on the footprint of the code. More complex or context switching / async type functions have to stay as they are.I think that you'd best let the optimizer do its job as it will (well, a decent optimizer that is) already make inline code for you and you may not know it. The advantage the optimizer has over you is that (1) it knows what it generates (2) it can relate this to cost vs other things (it has the big picture).As a developer, the sequential logic of your code probably impacts speed more than anything else, and this is not the days of the 8088 where you pondered cycles. In FS, the overwhelming speed impact comes from rendering and polygon counts, not the gauges (in most cases). The reason I say this is because execution speed is majorly impacted when you go from 2D gauge to VC, which runs the same gauge code in the back, but it's slower only because you've just increased rendering by about 9,000 polygons.In this context, adding a few inline functions isn't going to do a whole lot to address the major speed hog.In conclusion, I'd ignore inline functions altogether since at best you make little impact on the execution speed (compared to rendering), and at worst, you impede the code optimizer, which, in MS's case is pretty good, especially if you deal with C++ with the overloading and code decoration overheads.

[n4gix 4,947]

I just wanted to say thanks to those who replied with such helpful information...I'm still trying to wrap my old greymatter around this stuff, but will get there eventually! :)