View
214
Download
0
Embed Size (px)
Citation preview
Hume: a Domain-Specific Language for Programming with Bounded Resource
Hume: a Domain-Specific Language for Programming with Bounded Resource
Kevin Hammond, Pedro Vasconcelos, Sun Meng, Roy Dyckhoff,
Leonid TimochoukUniversity of St Andrews, Scotland
Greg Michaelson, Andy Wallace,Robert Pointon, Graeme McHale, Chunxiu Liu
Heriot-Watt University, Scotland
Jocelyn Sérot, Norman ScaifeLASMEA, Clermont-Ferrand, France
Martin Hofmann, Hans-Wolfgang LoidlLudwig-Maximilians Universität, München, Germany
Christian Ferdinand, Reinhold HeckmannAbsInt GmbH, Saarbrücken, Germany
http://www.hume-lang.org
Slide 2Kevin Hammond, University of St Andrews
ScotlandScotland
St Andrews, 1411Glasgow, 1452
Edinburgh, C18th
Highlands Speyside
Lowlands
Hume
Higher-order Uniform Meta-Environment
Hume
Higher-order Uniform Meta-Environment
David Hume
Scottish Enlightenment Philosopher and Sceptic
1711-1776
Funded byFunded by
€1.3M grant under EU Framework VIEmBounded: IST-2004-510255, 2005-2008
£200K grants from the UK’s EPSRCCost modelling for resource-bounded systems, 2002-2005
MetaHume: EP/C001346/0, 2005-2008
Travel grants from the British Council, CNRS etc.
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 5Kevin Hammond, University of St Andrews
Hume Research ObjectivesHume Research Objectives
• Real-Time, Hard Space Functional Programming
• Virtual Testbed for Space/Time Cost Modelling
• Generative, Domain-Specific Language Design
Slide 6Kevin Hammond, University of St Andrews
OverviewOverview
1. Hume Language Design and Examples
2. Stack and Heap Usage for Primitive Recursive Programs1. Cost Model
2. Inference Algorithm (Type-and-Effect System)
3. Results of the Analysis
4. Conclusions and Further Work
Slide 7Kevin Hammond, University of St Andrews
Hume Design Domain (1)Hume Design Domain (1)
QuickTime™ and aYUV420 codec decompressorare needed to see this picture.
Slide 9Kevin Hammond, University of St Andrews
The Embedded Systems Domain
The Embedded Systems Domain
• Some Facts– 98% of all processors are used in embedded systems
– by 2005, there will be 280 processors in the average home
– by 2010 the number of processors produced each year will double
– 75% of all processors are 8-bit or 16-bit designs
• And there are some sexy applications– CPUs found in mobile phones, DVD players, set-top boxes, ....
– and in mundane devices: washing machines, cookers, refrigerators,cars ...
Slide 10Kevin Hammond, University of St Andrews
State of the Art...State of the Art...
• Embedded Systems Engineering– big trend to high level software design (UML etc.)
– 80% of all embedded software is now written in C/C++
– 75% of embedded software is delivered late
– bugs can cost $14,000 each to fix!
• A Major Problem with C/C++ is Poor Memory Management– explicit allocation, deallocation
– pointer following
– etc. etc.
• No Accurate Method for Determining Memory Usage – profiling, guesswork(!!), approximation
Slide 12Kevin Hammond, University of St Andrews
Hume Design ObjectivesHume Design Objectives
• Targets embedded/critical applications– Hard real-time target– Formally bounded time and space– I/O managed through low-level “ports”/“streams”
» Memory-mapped, timed, interrupts or devices– Asynchronous concurrency model (multicore?)– Simple, easily costed, exception handling mechanisms– Transparent design and implementation: correctness by construction– uses Haskell FFI to allow external calls in C/assembler etc.
• High level of expressiveness/productivity– Rule-based system: concise & clear using functional notation– Runtime errors reduced by strong polymorphic types– Structured reuse through higher order functions– Thread management simplified by implicit concurrency/parallelism – Elimination of memory errors through automatic memory management
Reliability,
Expressibility,
Controllability,
Predictability,
Costability
Slide 13Kevin Hammond, University of St Andrews
FSA-derived NotationFSA-derived Notation• Based on generalised Mealy machines (see Michaelson et al. 2003)• Boxes encapsulate a set of rules each mapping inputs to outputs• Multiple inputs/outputs are grouped into tuples
• Sets of boxes are wired into static process networks (automata)• Boxes repeat indefinitely once a result is produced (tail recursion)• Boxes are asynchronous (ignored inputs/outputs)• Wires are single-buffered
box b ...match (patt11, ..., patt1k) -> (expr11, ..., expr1m)| ...| (pattn1, ..., pattnk) -> (expr11, ..., exprnm);
box b ...match (patt11, ..., patt1k) -> (expr11, ..., expr1m)| ...| (pattn1, ..., pattnk) -> (expr11, ..., exprnm);
Slide 14Kevin Hammond, University of St Andrews
Hume Language StructureHume Language Structure
• Boxes structure processes– Static process network
– Asynchronous communication
– Stateless
• Functions structure computations– Purely functional notation
– Pattern-matching relates inputs/outputs through functional expressions
box1
box2
box3
inport1
outport1 outport2
Slide 15Kevin Hammond, University of St Andrews
Declaration & Metaprogramming Layer
Hume Language StructureHume Language Structure
Coordination Layer
Expression Layer
Slide 16Kevin Hammond, University of St Andrews
Expression LayerExpression Layer
• Purely functional, strict, higher-order, polymorphic, stateless
• Matches are total
• Timeouts/space overflows are managed through exceptions
varid expr1 … exprn -- function/constructor application
(expr1, …, exprn) -- tuples
< expr1, …, exprn > -- vectors (sized)
[ expr1, …, exprn ] -- lists (bounded)
let decls in expr -- local value declarations
expr within cexpr -- timeout/space restriction
if expr then expr else expr -- conditional expression
case expr of matches -- case expression
expr :: type -- type cast
expr as type -- type coercion (cost implication)
Slide 17Kevin Hammond, University of St Andrews
Example: Parity Checker Example: Parity Checker type Bit = word 1;
type Parity = boolean;
parity true = (“true”,true);
parity false = (“false”,false);
box even_parity2
in (b::Bit, p::Parity)
out (show::string, p'::Parity)
match
(0,true) -> parity true
| (1,true) -> parity false
| (0,false) -> parity false
| (1,false) -> parity true;
wire even_parity2 (comm1, even_parity2.p' initially true) (comm2, even_parity2.p);
type Bit = word 1;
type Parity = boolean;
parity true = (“true”,true);
parity false = (“false”,false);
box even_parity2
in (b::Bit, p::Parity)
out (show::string, p'::Parity)
match
(0,true) -> parity true
| (1,true) -> parity false
| (0,false) -> parity false
| (1,false) -> parity true;
wire even_parity2 (comm1, even_parity2.p' initially true) (comm2, even_parity2.p);
comm1
p (true,…)
p’
b
even_parity2
comm2
Slide 18Kevin Hammond, University of St Andrews
Full Hume
PR-Hume
HO-Hume
FSM-Hume
Hume Language LevelsHume Language Levels
HW-Hume
Full Humerecursive functionsrecursive data structures
PR-Humeprimitive-recursive functionsprimitive-recursive data structures
HO-Humehigher-order non-recursive functionsnon-recursive data structures
FSM-Hume1st-order non-recursive functionsnon-recursive data structures
HW-Humeno functionsnon-recursive data structures
Slide 19Kevin Hammond, University of St Andrews
Metaprogramming Example: Fair Merge
Metaprogramming Example: Fair Merge
template merge
in (in1 :: int 32, in2 :: int 32)
out (o :: int 32)
fair
(x,*) -> x
| (*,y) -> y;
instantiate merge as m * 2;
wire M(b,inp1,inp2,outp) = b (in1, in2) (outp);
wire M(m{1}, sysin1, sysin2, m{2}.in1);
wire M(m{2}, m{1}.o, sysin3, sysout);
template merge
in (in1 :: int 32, in2 :: int 32)
out (o :: int 32)
fair
(x,*) -> x
| (*,y) -> y;
instantiate merge as m * 2;
wire M(b,inp1,inp2,outp) = b (in1, in2) (outp);
wire M(m{1}, sysin1, sysin2, m{2}.in1);
wire M(m{2}, m{1}.o, sysin3, sysout);
sysin1
o
in1
m{1}
sysin2
in2sysin3
in2
m{2}
in1
sysout
o
Slide 20Kevin Hammond, University of St Andrews
Exception HandlingException Handling
• Handled at box level– one exception handler per box
– no nested exceptions
• Low Cost Implementation– implemented as branch
– handlers must have trivially bounded cost
expr ::= “raise” expr | ...
handlers ::= handler1 "|" ... "|" handlern
handler ::= exnid patt "->" cexpr
expr ::= “raise” expr | ...
handlers ::= handler1 "|" ... "|" handlern
handler ::= exnid patt "->" cexpr
box ::= “box” boxid “in” ins “out” outs[ “handles” exnids ]( “match” | “fair” ) matches[ “handle” handlers ]
box ::= “box” boxid “in” ins “out” outs[ “handles” exnids ]( “match” | “fair” ) matches[ “handle” handlers ]
Slide 21Kevin Hammond, University of St Andrews
Exception Handling Example Exception Handling Example
f n = ...;
box overflow
in (c :: char)
out (v :: string 29)
handles TimeOut, HeapOverflow
match
n -> f n within 100us within 10KB heap
handle TimeOut x -> ”Timed Out: " ++ show x
| HeapOverflow x -> ”Heap Overflow: " ++ show x;
f n = ...;
box overflow
in (c :: char)
out (v :: string 29)
handles TimeOut, HeapOverflow
match
n -> f n within 100us within 10KB heap
handle TimeOut x -> ”Timed Out: " ++ show x
| HeapOverflow x -> ”Heap Overflow: " ++ show x;
v
c
overflow
Slide 22Kevin Hammond, University of St Andrews
Research ProblemsResearch Problems
• Construct layered cost models for Hume levels– Source-based
– Expose and solve costs for PR programs
• Stage Costs through Hume levels– allow use of software defined at higher levels
– automatic (formal) translation from high to low level
– may increase code size and costs
• Resource-aware abstract machine– expose resource usage
– allow compiler optimisations
Slide 24Kevin Hammond, University of St Andrews
A Type-and-EffectSpace Cost ModelA Type-and-EffectSpace Cost Model
• Relates language structure to <heap, max stack> usage– operational semantics expressed using sequent style
• Tuned to prototype Hume abstract machine interpreter– allows accuracy to be measured
– can be exploited by compiler
Both heap and stack
can be cleared after
a single box step
Derived from
theoretical
work on cost
analysis for parallel
programs
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Stack; Heap
Slide 25Kevin Hammond, University of St Andrews
Sized TypesSized Types
• Types are annotated with sizes– magnitude of natural
– length of a list
• Sizes can be weakened to any greater size– defined as a subtyping relation
– so 10 :: Nat11 but not 10 :: Nat9
means unknown size, greater than any other size, so 10 :: Nat
means undefined size, less than any other size
• Will be used to determine recursion bounds
10 :: Nat10
[6,1,2] :: [Nat6 ]3
Slide 26Kevin Hammond, University of St Andrews
Latent CostsLatent Costs
• Define costs for functions
• Allow costs to be captured for higher-order functions
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 27Kevin Hammond, University of St Andrews
Types and Effects for Stack/Heap Usage
Types and Effects for Stack/Heap Usage
• Size/Cost Expressions
• Types and Effects
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 28Kevin Hammond, University of St Andrews
Cost Rules: Basic ExpressionsCost Rules: Basic Expressions
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 29Kevin Hammond, University of St Andrews
Cost Rules: Conditionals/CasesCost Rules: Conditionals/Cases
Slide 30Kevin Hammond, University of St Andrews
Cost Rules:Function Applications
Cost Rules:Function Applications
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 31Kevin Hammond, University of St Andrews
Cost Rules: Function DeclsCost Rules: Function Decls
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 32Kevin Hammond, University of St Andrews
Cost InferenceCost Inference
• Restrict cost annotations in types to be variables
• Separately collect constraints on variables
• So, standard unification can be used on types
• Constraints must be solved to determine closed costs
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 33Kevin Hammond, University of St Andrews
Cost InferenceCost Inference
• Restrict cost annotations in types to be variables
• Separately collect constraints on variables
• So, standard unification can be used on types
• Constraints must be solved to determine closed costs
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Slide 34Kevin Hammond, University of St Andrews
Solving RecurrencesSolving Recurrences
• For recursive programs, the effect system generates recurrence relations on constraints
• These are solved to give closed forms– use e.g. Mathematica, called during cost analysis
– use an “oracle” of known recurrences
– write a new recurrence solver
• Constraints are monotonically increasing
Slide 35Kevin Hammond, University of St Andrews
Example: LengthExample: Length
• For the recursive length function
length [] = 0;
length (x:xs) = 1 + length xs;
• The type inferred is:
length :: [t7]^x21-{x19,x20}->nat^x27, {x19 >=7+6*x21, x20 >=2+4*x21,x27>=x21}
{stack,heap}
Slide 36Kevin Hammond, University of St Andrews
Example: TakeExample: Take
• For the recursive take function
take n [] = [];
take n (x : xs) = if n > 0 then (x : take (n-1) xs) else [];
• The type inferred is:
take :: nat^x53-{x51,x52}->[t118]^x56 -{x54,x55}->[t118]^x62,
{x51>=0,x52>=0,x54>=10+9*min(x53,x56), x55>=7+13*min(x53,x56),x62>=min(x53,x56)}
Slide 37Kevin Hammond, University of St Andrews
Example: Twice/MapExample: Twice/Map
• For the Higher-Order twice and map2 functionstwice f x = f (f x);map2 f [] = [];map2 f (x:[]) = [f x];map2 f (x:(y:[])) = [f x,f y];add1 x = 1+x;h x = map2 (twice add1) x;• The types inferred are:twice :: (t21-{x14,x15}->t21)-{x2,x3}->t21-{x4,x5}->t21,
{x2>=0,x3>=0,x4>=6+max(1+x14,1),x5>=x15+x15}map1 :: (t54-{x62,x63}->t73)-{x45,x46}->[t54]^x64
-{x47,x48}->[t73]^x65,{x45>=0,x46>=0,x47>=6+max(1+max(1+x62,1),2),x48>=max(8+x63,3),x65>=1}
add1 :: int-{x23,x24}->int, {x23>=7,x24>=4}h :: [int]^x112-{x75,x76}->[int]^x113,
{x75>=30,x76>=25,x113>=1}
Slide 39Kevin Hammond, University of St Andrews
ResultsResults
function heap (est) stack(est) heap(GHC -O2)
length: 10 181(181) 72(72) 1632length: 100 1711(1711) 612(612) 2357length: 1000 17011(17011) 6012(6012) 15630length: 10000 170011(170011) 60012(60012) 141626
reverse: 10 381(381) 88(98) 2080reverse: 100 26862(26862) 810(813) 35395reverse: 1000 2518512(2518512) 8008(8013) 3051874
twice/map2: 1 25(25) 30(30) 1564twice/map2: 2 38(38) 30(30) 1592lift 129(144) 89(89) --
function heap (est) stack(est) heap(GHC -O2)
length: 10 181(181) 72(72) 1632length: 100 1711(1711) 612(612) 2357length: 1000 17011(17011) 6012(6012) 15630length: 10000 170011(170011) 60012(60012) 141626
reverse: 10 381(381) 88(98) 2080reverse: 100 26862(26862) 810(813) 35395reverse: 1000 2518512(2518512) 8008(8013) 3051874
twice/map2: 1 25(25) 30(30) 1564twice/map2: 2 38(38) 30(30) 1592lift 129(144) 89(89) --
Slide 40Kevin Hammond, University of St Andrews
Results (Pump)Results (Pump)
• Cost model applied to mine drainage example– implemented in prototype Hume abstract machine compiler
– compared with measured dynamic runtime costs
box heap est heap actual stack est stack actual
pump 47 38 17 17environ 49 47 29 29water 54 54 24 24logger 119 105 39 31others 115 106 70 70wires 96 84 - -totals 480 434 179 171
box heap est heap actual stack est stack actual
pump 47 38 17 17environ 49 47 29 29water 54 54 24 24logger 119 105 39 31others 115 106 70 70wires 96 84 - -totals 480 434 179 171
2.6KB
v. 2.4KB
9%
Slide 42Kevin Hammond, University of St Andrews
RTLinux Memory Usage (Pump)RTLinux Memory Usage (Pump)
text data bss dec hex filename30146 52 30048 60246 eb56 hume_module.o
text data bss dec hex filename30146 52 30048 60246 eb56 hume_module.o
Module Size Used byhume_module 61904 0 (unused)rtl_sched 43200 0 [hume_module]rtl_fifo 10016 0 [hume_module]rtl_posixio 7232 0 [rtl_fifo]rtl_time 10064 0 [hume_module rtl_sched rtl_posixio]rtl 27216 0 [hume_module rtl_sched rtl_fifo rtl_posixio rtl_time]
Module Size Used byhume_module 61904 0 (unused)rtl_sched 43200 0 [hume_module]rtl_fifo 10016 0 [hume_module]rtl_posixio 7232 0 [rtl_fifo]rtl_time 10064 0 [hume_module rtl_sched rtl_posixio]rtl 27216 0 [hume_module rtl_sched rtl_fifo rtl_posixio rtl_time]
Slide 43Kevin Hammond, University of St Andrews
Vehicle Sim. StatisticsVehicle Sim. Statistics
Thu Aug 21 19:06:06 BST 2003
Box Statistics:
control: MAXRT = 53120ns, TOT = 1960041024ns, MAXHP = 57, MAXSP = 36env: MAXRT = 9101600ns, TOT = 1580087776ns, MAXHP = 49099, MAXSP = 129vehicle: MAXRT = 2973120ns, TOT = 2269933760ns, MAXHP = 49164, MAXSP = 133
Box heap usage: 98440 (99414 est)Box stack usage: 298 (319 est)
Stream/MIDI Statistics:
output1: MAXRT = 22688ns, TOT = 3188562720ns, MAXHP = 71, MAXSP = 1
...
Thu Aug 21 19:06:06 BST 2003
Box Statistics:
control: MAXRT = 53120ns, TOT = 1960041024ns, MAXHP = 57, MAXSP = 36env: MAXRT = 9101600ns, TOT = 1580087776ns, MAXHP = 49099, MAXSP = 129vehicle: MAXRT = 2973120ns, TOT = 2269933760ns, MAXHP = 49164, MAXSP = 133
Box heap usage: 98440 (99414 est)Box stack usage: 298 (319 est)
Stream/MIDI Statistics:
output1: MAXRT = 22688ns, TOT = 3188562720ns, MAXHP = 71, MAXSP = 1
...
Slide 44Kevin Hammond, University of St Andrews
Vehicle Sim. Statistics (2)Vehicle Sim. Statistics (2)
Wire Statistics:
control.0: MAX DELAY = 24544ns, MAXHP = 47env.0: MAX DELAY = 67072ns, MAXHP = 11vehicle.0: MAX DELAY = 33056ns, MAXHP = 47vehicle.1: MAX DELAY = 32448ns, MAXHP = 2vehicle.2: MAX DELAY = 9118688ns, MAXHP = 11vehicle.3: MAX DELAY = 9135968ns, MAXHP = 2
Total heap usage: 197022 (199078 est)Total stack usage: 597 (640 est)
Sat Aug 23 06:46:19 BST 2003
Wire Statistics:
control.0: MAX DELAY = 24544ns, MAXHP = 47env.0: MAX DELAY = 67072ns, MAXHP = 11vehicle.0: MAX DELAY = 33056ns, MAXHP = 47vehicle.1: MAX DELAY = 32448ns, MAXHP = 2vehicle.2: MAX DELAY = 9118688ns, MAXHP = 11vehicle.3: MAX DELAY = 9135968ns, MAXHP = 2
Total heap usage: 197022 (199078 est)Total stack usage: 597 (640 est)
Sat Aug 23 06:46:19 BST 2003
Slide 45Kevin Hammond, University of St Andrews
Related Work (Analysis)Related Work (Analysis)
• Regions (Tofte)– explicit labelled memory areas, automatic deallocation
• Cyclone (Morrissett)– C syntax, region inference
• Sized Types (Hughes & Pareto)– properties of reactive systems, progress, not inference, not cost
• Camelot/GRAIL (Sannella, Gilmore, Hofmann et al.)– stack/heap inference from JVM bytecode, parametric costs, tail recursion
• Worst-Case Execution Time Analysis (Wellings et al)– Java/Ada, probabilistic cache/execution costs
Slide 46Kevin Hammond, University of St Andrews
ConclusionsConclusions
• Cost Analysis forPrimitive Recursive, Higher-Order, Polymorphic Functions
– strict, purely functional notation
– generates cost equations plus recurrences
» recurrences solved by reference to an oracle or external solver
– soundness results under construction
• Good Practical Results Obtained in a number of cases– no loss of accuracy for non-recursive definitions
– exact worst-case solutions obtained for many definitions
– size-aliasing can cause problems for composing polymorphic definitions
Slide 47Kevin Hammond, University of St Andrews
Further Work/Work in ProgressFurther Work/Work in Progress
• Modelling– soundness proofs
» under construction• extends Hughes/Pareto MML to inference, different cost domain• many technical problems solved, some remaining
– resolve size aliasing problem– extend to general data structures– investigate Presburger arithmetic– application to other language paradigms: non-strict, object-oriented, C/C++
• Real-Time Models– Predictive real-time models need better hardware (especially cache) models– alternative real-time scheduling algorithms should be tried
• 1.3MEuro Framework VI Project (FET-OPEN)– with Jocelyn Sérot (LASMEA, France), Martin Hofmann (Ludwig-Maximilians Univerität,
Germany) and AbsInt GmbH (Saarbrücken, Germany)
Slide 48Kevin Hammond, University of St Andrews
Recent PapersRecent PapersInferring Costs for Recursive, Polymorphic and Higher-Order Functional Programs
Pedro Vasconcelos and Kevin HammondTo appear in Proc. 2003 Intl. Workshop on Implementation of Functional Languages (IFL ‘03), Edinburgh,Springer-Verlag LNCS, 2004. Winner of the Peter Landin Prize for best paper
Hume: A Domain-Specific Language for Real-Time Embedded SystemsKevin Hammond and Greg MichaelsonProc. 2003 Conf. on Generative Programming and Component Engineering (GPCE 2003), Erfurt, Germany,Springer-Verlag LNCS, Sept. 2003. Proposed for ACM TOSEM Fast Track Submission
FSM-Hume: Programming Resource-Limited Systems using Bounded AutomataGreg Michaelson, Kevin Hammond and Jocelyn SérotProc. 2004 ACM Symp. on Applied Computing (SAC ‘04), Nicosia, Cyprus, March 2004
The Design of HumeKevin HammondInvited chapter in Domain-Specific Program Generation,Springer-Verlag LNCS State-of-the-art Survey, C. Lengauer (ed.), 2004
Predictable Space Behaviour in FSM-Hume”,Kevin Hammond and Greg Michaelson,Proc. 2002 Intl. Workshop on Implementation of Functional Languages (IFL ‘02), Madrid, Spain, Sept. 2002, Springer-Verlag LNCS 2670, ISBN 3-540-40190-3,, 2003, pp. 1-16