Whole program compilation for embedded software: the ADSL experiment SCOPES’2001 Whole program compilation for embedded software: the ADSL experiment Johan Cockx johan.cockx@imec.be

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?

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)

=> 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

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

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.

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

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(…,…); …

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)

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