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

Re:inline will make your code *bigger*

[clem.dickey]

> The inline keyword is not supported by ANSI C - it is a C++ feature.

Inline is in C99, see section 6.7.4 of the standard.

That said, inlining can reduce code size if the function body object code is small relative to the parameter setup object code. Absent an inline feature in the compiler (what compiler could that be?), I think macros would be less dangerous than any specialized "inline preprocessor", even if there should be one.

Various...

[0x69]

As our Asker noted, macros are dangerous. For example, let a macro processor replace

foo = bar(i++);

and you'd better hope that the parameter isn't used more than once in the function's code - otherwise i will get incremented too often - hello bugs!

Flip side, you can eyeball the most commonly used functions for safe-to-macro-inline candidates and save space just on them.

An el-crapo compiler could easily burn more bytes with call & return code than a small function would need inline.

Are there any dusty & old or not-so-essential hunks of this code that could be ditched? A badly-written section that could be rewritten much smaller? Wordy user interface stuff to edit down?

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.

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.