I want to optimize/reduce memory usage of my software. One of the approaches that I'm looking at is to look for removing redundant and unnecessary code.
In my software there are lot of features (up to 3000) which can be activated/deactivated via a Feature Enable mechanism. What I am trying to do is to find how much RAM/FLASH a feature utilizes and then start evaluating with the biggest ones and see if they are required or not (Features not required can be safely deleted from the code). Also please note a function may have more than one feature within itself.
Our code would look something like this:
void foo (void)
{
if(TRUE == feature1_enable)
{
doSomething;
}
if(TRUE == feature2_enable)
{
doSomething;
}
//rest of the code
}
How can I calculate how much FLASH the code inside if statements is using? I cannot use final link map file as it provides data only about the function but not individual statements inside them. One solution that I have thought is to create an assembly listing file (.alst) out of the C code and then calculate the size of the instructions within the if statements which is nothing but the amount of FLASH utilized by these lines of code.
Kindly let me know if I am on the right track or if there is a better/easier way to do this?
I am using:
Processor: MPC5554 (POWER PC architecture)
Compiler: WindRiver Diab
If the logic is correct I would eventually write a script to search the enables and do the required calculations.
The only solution that comes to my mind that works with optimizations:
void foo (void)
{
#if 0 // disable feature 1 for size test
if(TRUE == feature1_enable)
{
doSomething;
}
#endf // feature 1
if(TRUE == feature2_enable)
{
doSomething;
}
//rest of the code
}
If you need to automate:
void foo (void)
{
#ifndef DISABLE_FEATURE_1_AT_COMPILE_TIME // disable feature 1 for size test
if(TRUE == feature1_enable)
{
doSomething;
}
#endf // feature 1
#ifndef DISABLE_FEATURE_2_AT_COMPILE_TIME // disable feature 2 for size test
if(TRUE == feature2_enable)
{
doSomething;
}
#endif // feature 2
//rest of the code
}
Then you can automate in your build script for every feature you have and measure the size of the feature alone. The most work you will have is adding all the defines now.
Related
Context: I am trying to create macros to create some efficient coroutines. In my concept, the function has multiple passes (running, cleaning, checking). Currently I implement it using switch/case The running part is a happy path, basically a fallthrough in a switch. While the other passes need to be invoked only in error modes. I would like it so that a label can jump to next label in sequence.
step1:
...
goto step2; // How to generate this statement? Equivalent of __COUNTER__+1
In other words macro code likle this:
BEGIN
AWAIT action1();
AWAIT action2();
AWAIT action3();
END
To become essentially
if (0) {
if (pass == CLEANING) {
clean1:
clean(1)
goto clean2; // <-
} else ...
}
case 1:
action1()
if (0) {
if (pass == CLEANING) {
clean2:
// no cleaning code here, compiler hopefully will optimize it out
// jumping from step 1 to step 3
goto clean3(); // <-
} else ...
}
case 2:
action2()
if (0) {
if (pass == CLEANING) {
clean3:
clean(3)
goto clean4(); // <-
} else ...
}
case 3:
action3()
if (0) {
clean4: // complete
}
I tried different approaches using switch statements & extra cases. Also tried building a skiplist to dispatch to correct case. But i'd like to do it without dispatching my "passes" through switch, and "connect" them using gotos directly. Generating label with __COUNTER__ is easy, but generating goto label ## __COUNTER__ + 1 seems to be impossible.
Are there any other options? (Let's say using anything GCC offers)
Jump table? The way i use macros, i can not build the jump table upfront because i dont know how many steps will be there
Multi-pass jump table? Creating some code that runs the full length of function first to create jump table seems to work, but it does not get optimized out on -O1/O2/Og, at least nothing I tried made it usable. It worked for O3, but it was very inefficient on others, which was really not very good for my needs.
Maybe if instead of incrementing __COUNTER__ i could somehow have access to "previous" value, i could work it out, but that seems to require some sort of runtime stuff. Saving counter value as enum does not really give me a way to concat labels anyway.
Using asm goto maybe? Is it possible to create label name dynamically like that? Using asm macro perhaps?
Labels-as-references seem to have the same problem that __COUNTER__ + 1 does not compute during preprocessing.
Creating a ton of macros like #define INCREMENT_3 4 seems to be the only idea that can actually work. But i'm afraid of running out of numbers. I dont understand exactly what does "translation unit" scope mean for __COUNTER__ - it's can be potentially more than one file, right?
In the end I decided to go with a set of INCREMENT_X X+1 macros. Even though I know casual use of macros are bad, it allowed me to achieve very tight code even onlow level of optimizations. Gotos are wonderfully optimized.
I implemented a coroutine system that implements re-entrancy, guard checks, defer blocks (also re-entrant), ability to unwind progress. In addition it has optional analyze pass that determines what kind of actions will happen in the function. By keeping macros to LHS of expressions, all regular functions calls are easily debuggable.
ENTER();
printf("NO EVEN STEP LOL\n");
AWAIT printf("Step %d\n", __LINE__);
AWAIT printf("Step %d\n", __LINE__);
// following expression will only run on function exit
DEFER printf("Deferring %d\n", __LINE__);
AWAIT printf("Step %d\n", __LINE__);
// if guard check faills, the function rolls back to this point
// running all defer blocks that were reached previously
// it also prevents function to execute further
GUARD !block;
printf("!!!!Before defer\n");
// following block will run either on function exit
// or on guard fail if execution reached it
DEFER {
printf("In defer lol\n");
// will suspend function based on value of await
// this is the complicated case of defer block being async
AWAIT await ? 666 : 1;
AWAIT printf("UNDEFER %d\n", __LINE__);
printf("/ In defer lol\n");
}
printf("/ defer\n");
AWAIT printf("Step %d\n", __LINE__);
AWAIT printf("Step %d\n", __LINE__);
AWAIT printf("Step %d\n", __LINE__);
// runs all defer blocks
LEAVE();
Here's a control graph on O1, which is barely different from O3
-O1: https://godbolt.org/z/xfnPeKrq3
-Og: https://godbolt.org/z/GMnM6Gx7E
I want to write a function in C and to put a condition in it. If the condition isn't met the program gives and error and prevents the user (developer) from compiling the code.
For example:
void func(int x)
{
if (x > 0)
{
//do stuff
}
else
{
//give an error and stops the code from compiling
}
}
prevents the user (developer) from compiling the code.
There's a problem there. You can decide on the user's behaviour, but you can't decide on the compilation of the program. If the code is right (right in the language sense, so it makes sense to the compiler), it will compile, else it won't. You can't make up new arbitrary rules for the compiler.
Before you can even run a program written in C, the compilation needs to be fulfilled.
Functions are called at run-time and so are the parameter values determined at run-time, too.
You can't make the compilation of your code dependent upon the variable x in C.
What you're trying to achieve is basically completely impossible.
Let's take an example. Assume that you want to manufacture an elevator, and you set the weight limit to 800 kilograms. You could build in something that makes the elevator stop if the weight exceeds the limit.
So take the scenario where we program the elevator so that it does not move if the weight limit is exceeded. That would typically be done with an assert() or something like that.
You could also in various way try to prevent this from happening, like making the elevator very small so that you cannot fit too many people. But that is not a fail safe option. We have restricted the volume, but nothing prevents a person from bringing a big chunk of solid gold into the elevator.
The point here is that you can measure the weight before moving the elevator, since this is done at runtime. But preventing someone from even trying to exceed the limit is virtually impossible.
In the general case, what you're asking for is completely impossible. What you can do is something like this:
void func(int x)
{
assert(x>0);
/* Do stuff */
}
And a slightly related thing that is possible is to create a test that is a part of the build process. You cannot prevent compilation the way you want, but you can use it to fail the whole build process. An example.
// main.c
int add(int x, int y)
{
return x+y;
}
bool test()
{
if(add(4,5) != 9) return false;
return true;
}
int main(int argc, char **argv)
{
if(strcmp(argv[1], "--test") == 0) {
if(!test()) {
printf("Test failed\n");
exit(EXIT_FAILURE);
}
// More tests
printf("All tests passed\n");
exit(EXIT_SUCCESS);
/* Rest of the main function */
}
Then you create a Makefile that compiles main.c and then calls ./a.out --test as a part of the build process. The above example is a very simple case, and for a more realistic case I would have made it a bit more sophisticated, but it shows how it can be done. Also, there are libraries that can take care of this kind of stuff, but this is a way to do it without having to use that.
if (a==5)
{
#define FLAG 1
}
#ifdef FLAG
{
// Execute this portion else not
}
#endif
I want to use this as flag variable and if the variable is defined(at runtime depending upon condition) then the piece if code in #ifdef shall be executed else not.
If this is not possible in c programming then please suggest me the best way to implement the same.
Which can help in faster execution of code. Also reduced compilation time
1) FLAG is not variable, it is a preprocessor symbol.
2) The preprocessor is running from top to bottom defining the symbols (or undefining them) regardless of your compilable code logic (so of course it can't depend on it), before it is even compiled. So in your example the #ifdef will always work.
3) To achieve the functionality you seem to want, just use a regular if/else statements.
bool flag = false;
if (a == 5)
{
flag = true;
}
if (flag)
{
// [...]
}
I'm working with a large SDK codebase glommed together from various sources of varying quality / competence / sanity from Linus Torvalds to unidentified Elbonian code slaves.
There are an assortment of styles of code, some clearly better than others, and it's proving an interesting opportunity to expand my knowledge / despair for the future of humanity in alternate measures.
I've just come across a pile of functions which repeatedly use a slightly odd (to me) style, namely:
void do_thing(foo)
{
do {
if(this_works(foo) != success)
break;
return(yeah_cool);
} while (0);
return(failure_shame_death);
}
There's nothing complicated being done in this code (I haven't cut 10,000 lines of wizardry out for this post), they could just as easily do:
if(this_works(foo) == success)
return(yeah_cool);
else
return(failure_shame_death);
Which would seem somehow nicer / neater / more intuitive / easier to read.
So I'm now wondering if there is some (good) reason for doing it the other way, or is it just the way they always do it in the Elbonian Code Mines?
Edit: As per the "possible duplicate" links, this code is not pre-processed in any sort of macro, it is just in the normal code. I can believe it might be due to a coding style rule about error checking, as per this answer.
Another guess: maybe you didn't quote the original code correctly? I have seen the same pattern used by people who want to avoid goto: they use a do-while(0) loop which at the end returns a success value. They can also break out of the loop for the error handling:
int doXandY() {
do {
if (!x()) {
break;
}
if (!y()) {
break;
}
return 0;
} while( 0 );
/* Error handling code goes here. */
globalErrorFlag = 12345;
return -1;
}
In your example there's not much point to it because the loop is very short (i.e. just one error case) and the error handling code is just a return, but I suspect that in the real code it can be more complex.
Some people use the do{} while(0); construct with break; inside the loop to be compliant in some way with MISRA rule 14.7. This rule says that there can be only single enter and exit point in the function. This rule is also required by safety norm ISO26262. Please find an example function:
int32_t MODULE_some_function(bool first_condition,bool second_condition)
{
int32_t ret = -1 ;
do
{
if(first_condition)
{
ret = 0 ;
break ;
}
/* some code here */
if(second_condition)
{
ret = 0 ;
break ;
}
/* some code here */
} while(0) ;
return ret ;
}
Please note however that such a construct as I show above violates different MISRA rule which is rule 14.6. Writing such a code you are going to be compliant with one MISRA rule, and as far as I know people use such a construct as workaround against using multiple returns from function.
In my opinion practical usage of the do{}while(0); construct truely exist in the way you should construct some types of macros.Please check below question, it was very helpful for me :
Why use apparently meaningless do-while and if-else statements in macros?
It's worth notice also that in some cases do{}while(0); construct is going to be completely optimized away if you compile your code with proper optimization option.
Hm, the code might be preprocessed somehow. The do { } while(0) is a trick used in preprocessor macros; you can define them like this:
#define some_macro(a) do { whatever(); } while(0)
The advantage being that you can use them anywhere, because it is allowed to put a semicolon after the while(0), like in your code above.
The reason for this is that if you write
#define some_macro(a) { whatever(); }
if (some_condition)
some_macro(123);
else
printf("this can cause problems\n");
Since there is an extra semicolon before the else statement, this code is invalid. The do { ... } while(0) will work anywhere.
do {...} while(0) arranged with "break" is some kind of "RAII for Plain C".
Here, "break" is treated as abnormal scope exit (kind of "Plain C exceptions"), so you can be sure that there is only one place to deallocate a resource: after a "while(0)". It seems slightly unusual, but actually it's very common idiom in the world of plain C.
I would guess that this code was originally written with gotos for error handling:
void do_thing(foo)
{
if(this_works(foo) != success)
goto error;
return(yeah_cool);
error:
return(failure_shame_death);
}
But at some point an edict came down from on high "thou shalt not use goto", so someone did a semi-automatic translation from goto style to loop-break style (perhaps with simple script). Probably when the code was merged/moved from one project to another.
I've started to dig into the GLib documentation and discovered that it also offers a unit testing framework.
But how could you do unit tests in a procedural language? Or does it require to program OO in C?
Unit testing only requires "cut-planes" or boundaries at which testing can be done. It is quite straightforward to test C functions which do not call other functions, or which call only other functions that are also tested. Some examples of this are functions which perform calculations or logic operations, and are functional in nature. Functional in the sense that the same input always results in the same output. Testing these functions can have a huge benefit, even though it is a small part of what is normally thought of as unit testing.
More sophisticated testing, such as the use of mocks or stubs is also possible, but it is not nearly as easy as it is in more dynamic languages, or even just object oriented languages such as C++. One way to approach this is to use #defines. One example of this is this article, Unit testing OpenGL applications, which shows how to mock out OpenGL calls. This allows you to test that valid sequences of OpenGL calls are made.
Another option is to take advantage of weak symbols. For example, all MPI API functions are weak symbols, so if you define the same symbol in your own application, your implementation overrides the weak implementation in the library. If the symbols in the library weren't weak, you would get duplicate symbol errors at link time. You can then implement what is effectively a mock of the entire MPI C API, which allows you to ensure that calls are matched up properly and that there aren't any extra calls that could cause deadlocks. It is also possible to load the library's weak symbols using dlopen() and dlsym(), and pass the call on if necessary. MPI actually provides the PMPI symbols, which are strong, so it is not necessary to use dlopen() and friends.
You can realize many of the benefits of unit testing for C. It is slightly harder, and it may not be possible to get the same level of coverage you might expect from something written in Ruby or Java, but it's definitely worth doing.
At the most basic level, unit tests are just bits of code that execute other bits of code and tell you if they worked as expected.
You could simply make a new console app, with a main() function, that executed a series of test functions. Each test would call a function in your app and return a 0 for success or another value for failure.
I'd give you some example code, but I'm really rusty with C. I'm sure there are some frameworks out there that would make this a little easier too.
You can use libtap which provides a number of functions which can provide diagnostics when a test fails. An example of its use:
#include <mystuff.h>
#include <tap.h>
int main () {
plan(3);
ok(foo(), "foo returns 1");
is(bar(), "bar", "bar returns the string bar");
cmp_ok(baz(), ">", foo(), "baz returns a higher number than foo");
done_testing;
}
Its similar to tap libraries in other languages.
Here's an example of how you would implement multiple tests in a single test program for a given function that might call a library function.
Suppose we want to test the following module:
#include <stdlib.h>
int my_div(int x, int y)
{
if (y==0) exit(2);
return x/y;
}
We then create the following test program:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <setjmp.h>
// redefine assert to set a boolean flag
#ifdef assert
#undef assert
#endif
#define assert(x) (rslt = rslt && (x))
// the function to test
int my_div(int x, int y);
// main result return code used by redefined assert
static int rslt;
// variables controling stub functions
static int expected_code;
static int should_exit;
static jmp_buf jump_env;
// test suite main variables
static int done;
static int num_tests;
static int tests_passed;
// utility function
void TestStart(char *name)
{
num_tests++;
rslt = 1;
printf("-- Testing %s ... ",name);
}
// utility function
void TestEnd()
{
if (rslt) tests_passed++;
printf("%s\n", rslt ? "success" : "fail");
}
// stub function
void exit(int code)
{
if (!done)
{
assert(should_exit==1);
assert(expected_code==code);
longjmp(jump_env, 1);
}
else
{
_exit(code);
}
}
// test case
void test_normal()
{
int jmp_rval;
int r;
TestStart("test_normal");
should_exit = 0;
if (!(jmp_rval=setjmp(jump_env)))
{
r = my_div(12,3);
}
assert(jmp_rval==0);
assert(r==4);
TestEnd();
}
// test case
void test_div0()
{
int jmp_rval;
int r;
TestStart("test_div0");
should_exit = 1;
expected_code = 2;
if (!(jmp_rval=setjmp(jump_env)))
{
r = my_div(2,0);
}
assert(jmp_rval==1);
TestEnd();
}
int main()
{
num_tests = 0;
tests_passed = 0;
done = 0;
test_normal();
test_div0();
printf("Total tests passed: %d\n", tests_passed);
done = 1;
return !(tests_passed == num_tests);
}
By redefining assert to update a boolean variable, you can continue on if an assertion fails and run multiple tests, keeping track of how many succeeded and how many failed.
At the start of each test, set rslt (the variables used by the assert macro) to 1, and set any variables that control your stub functions. If one of your stubs gets called more than once, you can set up arrays of control variables so that the stubs can check for different conditions on different calls.
Since many library functions are weak symbols, they can be redefined in your test program so that they get called instead. Prior to calling the function to test, you can set a number of state variables to control the behavior of the stub function and check conditions on the function parameters.
In cases where you can't redefine like that, give the stub function a different name and redefine the symbol in the code to test. For example, if you want to stub fopen but find that it isn't a weak symbol, define your stub as my_fopen and compile the file to test with -Dfopen=my_fopen.
In this particular case, the function to be tested may call exit. This is tricky, since exit can't return to the function being tested. This is one of the rare times when it makes sense to use setjmp and longjmp. You use setjmp before entering the function to test, then in the stubbed exit you call longjmp to return directly back to your test case.
Also note that the redefined exit has a special variable that it checks to see if you actually want to exit the program and calls _exit to do so. If you don't do this, your test program may not quit cleanly.
This test suite also counts the number of attempted and failed tests and returns 0 if all tests passed and 1 otherwise. That way, make can check for test failures and act accordingly.
The above test code will output the following:
-- Testing test_normal ... success
-- Testing test_div0 ... success
Total tests passed: 2
And the return code will be 0.
There is nothing intrinsically object-oriented about testing small pieces of code in isolation. In procedural languages you test functions and collections thereof.
If you are desperate, and you'd have to be desperate, I banged together a little C preprocessor and gmake based framework. It started as a toy, and never really grew up, but I have used it to develop and test a couple of medium sized (10,000+ line) projects.
Dave's Unit Test is minimally intrusive yet it can do some tests I had originally thought would not be possible for a preprocessor based framework (you can demand that a certain stretch of code throw a segmentation fault under certain conditions, and it will test it for you).
It is also an example of why making heavy use of the preprocessor is hard to do safely.
The simplest way of doing a unit test is to build a simple driver code that gets linked with the other code, and call each function in each case...and assert the values of the results of the functions and build up bit by bit...that's how I do it anyway
int main(int argc, char **argv){
// call some function
int x = foo();
assert(x > 1);
// and so on....
}
Hope this helps.
With C it must go further than simply implementing a framework on top of existing code.
One thing I've always done is make a testing module (with a main) that you can run little tests from to test your code. This allows you to do very small increments between code and test cycles.
The bigger concern is writing your code to be testable. Focus on small, independent functions that do not rely on shared variables or state. Try writing in a "Functional" manner (without state), this will be easier to test. If you have a dependency that can't always be there or is slow (like a database), you may have to write an entire "mock" layer that can be substituted for your database during tests.
The principle unit testing goals still apply: ensure the code under test always resets to a given state, test constantly, etc...
When I wrote code in C (back before Windows) I had a batch file that would bring up an editor, then when I was done editing and exited, it would compile, link, execute tests and then bring up the editor with the build results, test results and the code in different windows. After my break (a minute to several hours depending on what was being compiled) I could just review results and go straight back to editing. I'm sure this process could be improved upon these days :)
I use assert. It's not really a framework though.
You can write a simple minimalistic test framework yourself:
// test_framework.h
#define BEGIN_TESTING int main(int argc, char **argv) {
#define END_TESTING return 0;}
#define TEST(TEST_NAME) if (run_test(TEST_NAME, argc, argv))
int run_test(const char* test_name, int argc, char **argv) {
// we run every test by default
if (argc == 1) { return 1; }
// else we run only the test specified as a command line argument
for (int i = 1; i < argc; i++) {
if (!strcmp(test_name, argv[i])) { return 0; }
}
return 0;
}
Now in the actual test file do this:
#include test_framework.h
BEGIN_TESTING
TEST("MyPassingTest") {
assert(1 == 1);
}
TEST("MyFailingTest") {
assert(1 == 2);
}
END_TESTING
If you want to run all tests, execute ./binary without command line arguments, if you want to run just a particular test, execute ./binary MyFailingTest