A Case Study on Partial Evaluation in Embedded Software Design

1
A Case Study on Partial Evaluation in Embedded
Software Design

• Michael Jung
• Ralf Laue
• Sorin Alexander Huss
• Integrated Circuits and Systems Lab
• Darmstadt University of Technology

2
Introduction

• Embedded systems software design software
  generators help to achieve both resuability and
  efficiency
• Generators usually implemented by hand
• time-consuming and error-prone
• Implementing software generators with partial
  evaluation constitute way out

3
Overview

• Problem illustration
• Introduction to basics
• OSEK
• Partial Evaluation
• Implementation
• Results

4
Problem Illustration
Reusability
Efficient Implementation
High Degree of Configurability (Parameters,
Indirections, ...)
Conflicting Goals
Hand Optimized and Specialized Code
Low Level Machine- Intimate Code
High Level of Abstraction (e.g.OOP)
Hard economical constraints led to the fact that
embedded software is usually highly specialized
for the application at hand and therefore not
reusable
5
Binding Time of Parameters

• Parameterization happens at different times
  during product life cycle
• Parameters bound to concrete values before run
  time are called static. Run time parameters are
  called dynamic
• This distinction is usually not exploited in
  reusable software modules

Configuration
6
Generative Programming

• Generative Programming takes advantage of static
  parameters
• Domain Specific Language
• specifies static parameters at a high level of
  abstraction
• Generator
• generates optimized code from generic components

7
OSEK OS - Generator

• OSEK is a specification for embedded OS
  (developed by university and automotive industry)
• Domain Specific Language for OSEK is OIL (OSEK
  Implementation Language)
• OIL specifies features like number of tasks and
  resources or level of error management
• Generator applies OIL specification and generates
  specialized code containing only needed
  functionality

8
OSEK Generation Flow
optional OSEK Builder
1
Application Configuration File (OIL)
"C" code
User's source code
System Generator
OSEK OS Kernel
Files produced by SG
"C" code
"C" code
Compiler
Object libraries
Linker
Device Driver
Executable File
9
Shortcomings of Generators

• Generators are typically implemented by hand
  (e.g. OSEK)
• Verifying correctness of hand-written generators
  is hard
• Partial Evaluation promises some means of
  automation

10
Partial Evaluation

• A Partial Evaluator computes a Generator from
• a generic parameterizable software module
• a division of the parameters in static and
  dynamic ones
• Given concrete values for the static parameters
  this Generator computes a specialized software
  module exhibiting the same behaviour as the
  original program with the same inputs

11
Partial Evaluation Example
x dynamic n static
int power(int x, unsigned n) int r1 while
(n) if (n1) rrx xxx nngtgt1
return r
n 3
12
Partial Evaluation Advantages

• Generators are typically implemented by hand
• division of parameters in static and dynamic ones
  is build into generator ? cannot easily be
  changed later on
• With Partial Evaluation generators for all 2P can
  automatically be synthesized
• Verifying correctness of hand-written generators
  is hard
• Assuming the Partial Evaluator is correct only
  the generic program has to be checked

13
Implementation Basic Ideas

• OSEK-Implementation with C-Mix/II (which
  processes the complete C-syntax)
• C-Mix/II creates an OSEK-generator out of generic
  OS code
• Given the information specified in the OIL-file,
  this generator computes specialized OS code
• Instead of writing an own parser for OIL, we
  mapped OIL to XML and used an XML-parser

14
Implementation

• Two function-types have to be specialized
• Initialization-functions creation(malloc) and
  initialization of OS-data-structures
• API-functions include only the necessary code
  paths for the chosen functionality
• For this, the functions get an additional
  parameter containing the XML-tree containing the
  OIL-information, which is static and will not be
  present in the specialized code

15
Implementation
User written/designed
Code to be specialized
i386
3rd party tools
Part of OSEK-Implementation
Partition static/dynamic
C-Mix/II
Text-file
Program
Generator
OIL/XML
Specialized Code
General Code
Application Code
M68K
Compiler/Linker
Executable
16
Example Initialization

• TaskRefType OSEK_ready_queues_head
• TaskRefType OSEK_ready_queues_back
• void OSEK_init_ready_queue(xmlNodePtr config)
• unsigned int priority_mapping, maxPriority
• priority_mapping create_priority_mapping(confi
  g)
• maxPriority priority_mappingmax_priority(conf
  ig)1
• OSEK_ready_queues_head
• malloc(sizeof(TaskRefType)maxPriority)
• OSEK_ready_queues_back
• malloc(sizeof(TaskRefType)maxPriority)
• for (i0 iltmaxNeededPriority i)
• OSEK_ready_queues_headi INVALID_TASK
• OSEK_ready_queues_backi INVALID_TASK
• // for
• // OSEK_init_ready_queue

17
Example Intialization

• Number of tasks gt 3
• Exactly 3 different unique priorities were
  assigned to the tasks
• Gaps between priorities possible

• TaskRefType OSEK_ready_queues_head3
• INVALID_TASK, INVALID_TASK, INVALID_TASK
• TaskRefType OSEK_ready_queues_back3
• INVALID_TASK, INVALID_TASK, INVALID_TASK

18
Example API-Function

• StatusType InitMessage(
• SymbolicName msg,
• ApplicationDataRef data,
• xmlNodePtr config)
• read_COM_xml(config)
• if (COM_cmix_use_parameter_access)
• COM_error_last_message msg
• COM_error_last_dataref data
• // if
• if (COM_cmix_use_GetServiceId)
• COM_error_last_service_called
• COMServiceId_InitMessage
• ...

if (COM_cmix_COMStatus_is_extended) if
((msg lt 0) (msg gt COM_cmix_message_amo
unt) (COM_MessageStoremsg.type !
RECEIVE_UNQUEUED)) if
(COM_cmix_user_error_hook
!COM_cmix_ErrorHook_is_active)
COM_cmix_ErrorHook_is_active 1
COMErrorHook(E_COM_ID)
COM_cmix_ErrorHook_is_active 0 // if
return E_COM_ID // if // if
COM_MessageStoragemsg.content.\
receive_unqueued_internal.datadata return
E_OK // InitMessage
19
Example API-Function

• StatusType InitMessage(SymbolicName msg,
• ApplicationDataRef data)
• if ((msg lt 0)
• (msg gt COM_cmix_message_amount)
• (COM_MessageStoragemsg.type !
• RECEIVE_UNQUEUED))
• return E_COM_ID
• // if
• COM_MessageStoragemsg.content.\
• receive_unqueued_internal_datadata
• return E_OK
• // InitMessage

• Selected
• No error reporting
• No error hooks
• Sanity checks

20
Result Code Sizes
21
Results Observed Weaknesses

• Although the implementation was feasible, there
  were
• some problems, because of limited functionality
  of
• the used Partial Evaluator (C-Mix/II)
• Reflection
• Need to access objects (i.e., task functions) via
  their name
• void GetFuncPtr( const char name)
• Cross partial evaluation
• Generator is executed on host machine, generating
  code for embedded system hardware
• Need for identical semantics on both machines

22
Results Observed Weaknesses

• Code bloat
• Unrolling loops, different versions of one
  function
• In our case only elimination of unused code
• Function signatures
• Partial evaluator changes function signature?
  not desirable for reusable software modules
• No splitting of structs
• C-Mix/II if any part of a struct is dynamic,
  whole struct is dynamic
• Spaghetti code
• C-Mix/II control flow implemented with goto

23
Conclusion

• Conclusion
• We consider partial evaluation a promising
  approach to build efficient reusable software for
  embedded systems
• A couple of problems still have to be addressed
  with better tools
• Future Work
• Implementation of a Partial Evaluator considering
  the domain of resource constrained embedded
  systems
• Cross-Partial Evaluation
• Code Bloat

24
Thanks for your attention
Questions?
References 1 The OSEK Group OSEK/VDX Operating
System Version 2.2.2, July 2004 2 K. Czarnecki,
U.W. Eisenecker Generative Programming -
Methods, Tools, and Applications, Addison Wesley,
2000 3 N. D. Jones, C. K. Gomard, and P.
Sestoft Partial Evaluation and Automatic Program
Generation, Prentice Hall, 1993 4 R. Laue
Fallstudie Implementierung von Software
Generatoren mittels partieller Evaluierung, TU
Darmstadt, Diplomarbeit, November 2003 5 M.
Jung, and S.A. Huss Fast Points-to Analysis for
Languages with Structured Types, SCOPES 2004,
Springer LNCS 3199, 2004
25
Result Initialization
unsigned char heap_location_112 unsigned char
heap_location_212 TaskRefType
OSEK_ready_queues_head TaskRefType
OSEK_ready_queues_back void OSEK_init_ready_que
ue() OSEK_ready_queues_head
heap_location_1 OSEK_ready_queues_back
heap_location_2 OSEK_ready_queues_head0
INVALID_TASK OSEK_ready_queues_back0
INVALID_TASK OSEK_ready_queues_head1
INVALID_TASK OSEK_ready_queues_back1
INVALID_TASK OSEK_ready_queues_head2
INVALID_TASK OSEK_ready_queues_back2
INVALID_TASK // OSEK_init_ready_queue