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?"

Comments

Re:Port it.

[Twirlip of the Mists]

I think both you and this guy missed an important detail.

I have inherited the C code for an embedded system

There's a good chance that the compiler this person is using is the only one that's available for the architecture in question. I mean, he could be talking about a microwave oven or a car ignition system or something.

inline will make your code *bigger*

[jspayne]

Did I miss something, or is the poster asking how to *reduce* code size ("run out of code space") - using inline will make your code bigger by duplicating the source. Are you actually running out of stack (data) space?

What compiler is being used? The inline keyword is not supported by ANSI C - it is a C++ feature. However many C compilers support a proprietary inline declaration. Examples:

Green Hills: __inline
Diab: __inline__
Others use: #pragma inline

So, RTFM. Also, check the docs for inlining optimizations.

Jeff

You're right, but...

[sunryder]

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.

Macros aren't necessarily as dangerous...

[funbobby]

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.

Complete Solution Available

[Euphonious Coward]

Assuming that Gcc doesn't target your platform (otherwise you could just switch to Gcc) you can get an excellent inlining preprocessor from Comeau Computing (look it up on Google), at a very reasonable price.

Their preprocessor happens also to be a complete C++ compiler. You don't have to use the rest of the C++ features. (You might, for example, want to turn off exception handling.)

Any half-assed preprocessor that just folds function bodies into line is likely to be much worse than using macros. The worst possible outcome is code that's in some weird private language that only your weird private tools understand. (Cf. Qt/KDE)

Use a macro processor, just not the C preprocessor

[ComputerSlicer23]

Using M4 or some other preprocessor should alleviate a lot of the problems. You can use it to preprocess the code, before it gets to the C preprocessor. Possibly use a version of C-front, which outputs C code from C++, then just compile the C it outputs. Some of the C-front compilers support inlining no problem. Otherwise, it's relatively simple to follow the rules to make using straight C macros not be dangerous. Everything you pass to a macro is a locally declared variable, with no expressions, and it'll act just the way you want. It's a pain in the ass to remember, but then again, you are writting an embedded system.

"Dear Slashdot"

[kawika]

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?

are you kidding?

[selectspec]

I have inherited the C code for an embedded system project that has run out of code space.

Stack space? Inlining is not neccessarily going to solve this problem. Recursion is probably your problem. Also, make the stack larger if possible.

Instruction space? Inlining will most likely make this worse, except in extremely abstracted code where the overhead to make the function call is more than the inline expense.

...the compiler doesnt generate efficient code for stack handling.

The solution is to fix the compiler's stack handling. When the compiler is the problem, fix the compiler. I've never heard of an embedded systems project that didn't include someone hacking with the compiler.

Ideally I would direct the compiler to 'inline' a lot of the functions but unfortunately it doesnt support the inline keyword.

Changing the compiler to support the keyword is probably a pain in the butt. However, there are very few C compilers which don't support some form of the inline keyword. Double check your docs.

Using macros is dangerous...

Macros Dangerous? That's rediculous. I suppose creating some wierd perl script to munch through your source code ripping up inline functions and auto-generating C files that will never have the propper dependecies is safe?

...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?"

This is crazy! Autogenerating code is a great way to totally fuck up your build system. You'll never get your dependencies right and you'll end up building your entire project every time. Writing a tool that will parse your source code and identify the inline keyword is *exactly* as complicated as making the compiler understand the inline keyword. Don't do some bizzare on-off wierd hack. Instead, if you really want to use inline, bust out your compiler source and get cranking. If you don't have the compiler source, bust out gcc source and get cranking porting gcc to your hardware.