A Case Study on Partial Evaluation in Embedded Software Design

1 / 25
About This Presentation
Title:

A Case Study on Partial Evaluation in Embedded Software Design

Description:

Code bloat: Unrolling loops, different versions of one function ... Code Bloat. 2005-05-17. 24. ICS. INTEGRATED. CIRCUITS AND. SYSTEMS LAB ... –

Number of Views:88
Avg rating:3.0/5.0
Slides: 26
Provided by: michae651
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com