…
sched_lock()
if (error_1) {
err = EINVAL;
goto out;
}

if (error_2) {
err = ENOMEM;
goto out;
}

// real work happens here

out:

sched_unlock();
return err;

…
sched_lock()
if (error_1)
goto out;

if (error_2)

Here’s the stats:

Metrics Summary For Checkpoint ‘Baseline’
——————————————————————————————–

Parameter Value
========= =====
Project Directory Z:\home\patrick\src\e7\prex\
Project Name e7
Checkpoint Name Baseline
Created On 11 Apr 2011, 12:42:03
Files 2071
Lines 320,507
Statements 151,780
Percent Branch Statements 15.6
Percent Lines with Comments 25.7
Classes Defined 82
Methods Implemented per Class 5.93
Average Statements per Method 7.1
Maximum Complexity 109
Maximum Block Depth 9+
Average Block Depth 1.37
Average Complexity 4.44
Functions 5,961

——————————————————————————————–
Block Depth Statements

0 32,735
1 67,619
2 25,782
3 17,484
4 5,092
5 2,111
6 749
7 160
8 39
9+ 9
——————————————————————————————–

const: 5635
volatile: 209
static: 4995
case: 4307
goto: 1891

BTW, I’m really enjoying your comments!

I recently did a benchmarking of GCC for MSP430 vs IAR – compiling the same code (about 600 lines of source) which included an interrupt handler. For both compilers I set maximum optimisation (for smallest code side). I was kind of stunned by the results. The code side generated for GCC was about 50% larger than IAR. This was all confirmed by inspecting the generated code for each and counting bytes.

While at it I checked a number of other compilers and was astonished to find that some of them can’t even generate a proper compiler listing file. How on earth can a serious embedded engineer work with a compiler where you can’t see what it does? (Looking at the mnemonics does not count, I want to see the byte stream and the size / offset from the start for every function.)

I have one example of two programs. They are both running on the same hardware, they are nearly identical in size and functionality (safety-critical field bus systems). But the code quality is very different.

One of the programs contains excellent code. Very easy to read, throughoutly tested with static analyzers and with full MISRA-C compliance. The other program contains sloppy, complex and fairly unreadable/unmaintainable code, with lots of MISRA-C violations.

Results below. I stripped away all search hits of volatile that directly referred to hardware register maps, as that seems highly irrelevant to the quality of the program. Also, both programs are dealing with dip-SWITCHes, so the number of switch hits is mostly from code comments regarding dip-switches… Lesson learnt from that is that one should probably only run “grep” on raw pre-processor output.

Files: 36
Lines: 14,269
Statements: 5,227
% Branches: 10.9
% Comments: 40.6
Functions: 171
Avg stms/func: 19.3
Max complexity: 69
Max depth: 9+
Avg depth: 0.86
Avg complexity: 4.25
volatile: 41
const: 197
static: 117
switch: 20

Files: 41
Lines: 15,427
Statements: 5,866
% Branches 12.8
% Comments 38.2
Functions: 189
Avg stms/func: 22.3
Max complexity: 133
Max depth: 9+
Avg depth: 1.09
Avg complexity: 4.87
volatile: 43
const: 201
static: 171
switch: 23

As you can see, the results are almost identical. Just by the metrics, it is impossible to tell which one that is the good program (it is the 1st one).