Slashdot Mirror
Pre-Processers for Inlined C Code?
Scott Snell asks: "I have inherited the C code for an embedded system project that has run out of code space. The source code is highly fragmented and the compiler doesnt generate efficient code for stack handling. Ideally I would direct the compiler to 'inline' a lot of the functions but unfortunately it doesnt support the inline keyword. Using macros is dangerous and manually inlining is driving me crazy! What I need is a tool that will take the source files, look for the 'inline' keyword and generate new source files that are inlined. Any ideas?"
Porting it to a compiler that supports inline functions might be easier than manually inlining the functions, depending on how non-standard the C in your program is.
Regards, Guspaz.
You're right: inline functions will generate larger compiled code sizes if the function is called often enough. However, it is not impossible that the overhead of calling the function generates more machine code than inlining the code. This would depend on the system he is targetting and the size/purpose of the function that is to be inlined.
On the other hand, I reread the post several times, and I'm probably wrong, but it almost sounds like he is running into a problem with "source code" space. Could it be that he is compiling the code on the embedded system?
At any rate, this post should be modded as Offtopic because it doesn't really attempt to answer the problem. I'm guess I'm just trying to figure out if there isn't maybe another solution.
First off, macros are generally evil. With that out of my system, you're also not quite correct.
Macros are simply 'cut-n-pasted' into the source, then compiled. Thus, no type checking takes place.
There are many reasons you should try not to use macros. Personally, I try to avoid any preprocessing when I can. The C++ FAQ Lite is much better at explaining it all that I. More specifcially, try Reason 1 Reason 2 Reason 3 Reason 4
as using some strange non-standard tool or hack to get around this, or letting your code get really big and ugly from "manually inlining" everything.
Macros have their dangers, but at least their dangers are well understood, and should be familiar to anyone who is writing embedded C. It is the commonly used solution to your problem, which makes it nice for keeping your code maintainable.
If you use a trick to get around the problem, it will just be another thing to confuse the next person who has to maintain the code.
I need to squeeze down some C code to fit into an embedded system. I can't tell you much about it, for example the processor type, what compiler I'm using, how much of the code is libraries and how much is our own code, or how far over the limit we are.
I think the problem can be solved by inlining functions. Yes, inlining. Even though this generally increases code size, I think it's the solution in this case. You don't have enough information to argue about this, so trust me. Just give me a solution. Can you write me a Perl program, for example? I told you that the word you are looking for is "inline". Is there anything else you need to know?
That said, you are looking to refactor your software anyway, you might as well do it right, possibly starting with picking a newer more modern toolset, architecting the code differently to allow you to optimize for stack/code/data space, and many other factors. Will this take time, of course, but it might not take as long as a simple little hack, plus give you better results, and the ability to improve in the future. Will management buy it ??? Probably not, so just tell them you are inlining everything, and give them so much more out the back end.
I have mod points and I am not afraid to use them