1. Whole program compilation for embedded software: the ADSL experiment
SCOPES’2001
Whole program compilation for embedded software: the ADSL experiment
Johan Cockx

2. Embedded software dilemma: flexible&reusable or fast&small?
flat
design-specific optimizations
C / assembly
modular
object-oriented
C++
How much overhead?
Can it be removed?

3. The ADSL experiment ARM processor ADSL software
130,000 lines C/C++ & preprocessor modular + OO traces multi-thread, dyn. allloc.
Manually optimized footprint (code+data)
Virtuoso RTOS
interrupts
memory-mapped I/O
ADSL hardware (data path + controllers)

4. => local optimization is not good enough
Where is the overhead?
Code written for the general case
Many small procedures
Polymorphic (virtual) calls
=> local optimization is not good enough

5. Optimization techniques: a whole-program approach
1. Aggressive use of inter-procedural techniques
2. OO-specific optimization
3. Data allocation optimization

6. Example: removing polymorphic calls
Abstract
Abstract* a;
… a->foo();
foo()
replace call via function pointer by direct calls
enable inlining
Concrete1
foo() { … }
Concrete2
foo() { … }
Abstract* a; …
switch (a->type_tag) {
case CONCRETE1: a->Concrete1::foo();
case CONCRETE2:
a->Concrete2::foo(); }
The initial approach starts from the runtime objects and is typical for an “Object-Based” approach. There’s no use of “Object-Oriented” features like polymorphism. The OO approach, although it looks more elaborate, has identical runtime objects. There will be only one “Button” object and one “Lamp” object instantiated, just as for the object-based design.
The concept (some kind of switch that controls a switchable object) is hidden in the object-based design. This concept is lifted from the specific instances and made explicit, I.e. becomes reusable. It also clarifies the designers intend.
In an object-based design there’s a close coupling between the Button and the Lamp. Eventually we end up with a “Button_For_Lamp”, “Button_For_Ventilator”, …etc. The situation gets worse when we want to add different “kinds” of buttons like a remote control, GUI button, … The OO approach allows for any Switch to control any switchable.
Initially the designer needs less “lines” to code the object-based design compared to the OO design.
Reusing is not possible without duplication of code in an object-based design while the OO design offers automatic reuse of high-level algorithms. Duplication is of course a nightmare when for instance a bug is solved in the algorithm. We need to track all duplications and apply the changes by hand. In the OO design the algorithm is defined once so any solved bug is automatically propagated.

7. Example: data inlining
Eliminate:
dynamic allocation
pointer de-reference
polymorphic calls
class A
B* b; A() { b = new B; } ~A() { delete b; } void f() { b->g();}
class B
class A’
C b; A(): b() {} ~A() {} void f() { b.g();}
class C

8. Example: dynamic allocation removal
Eliminate dynamic allocation
Re-use stack memory already needed for other call tree branches
void teq(…,short size,…) {
float* Ryy;
Ryy = new float[size];
… teq computation …
delete Ryy; }
void teq(…,…) {
float Ryy[64];
… teq computation … }
teq(…,64,…); …
teq(…,…); …

9. ADSL result: footprint -33%
Unoptimized
ARM C++ optimized (-O2 -Ospace)
Inlining, dead code, const. prop.
Virtual call elimination
400kB
Data alloc. optim.
200kB
106%
100%
83%
82%
67%
Total memory footprint (code + data)

10. Main benefit: modular & reusable embedded software
Conclusions
Whole program optimization is worthwhile
ADSL: footprint -33%, traditional compiler -6%
Manual optimization ruins modularity
a compiler is desirable
Compiler must be RTOS-aware
dynamic allocation, stack sizes
Main benefit: modular & reusable embedded software