Hume: a Domain-Specific Language for Programming with Bounded Resource

About This Presentation
Title:

Hume: a Domain-Specific Language for Programming with Bounded Resource

Description:

Hume: a Domain-Specific Language for Programming with Bounded Resource Kevin Hammond, Pedro Vasconcelos, Sun Meng, Roy Dyckhoff, Leonid Timochouk –

Number of Views:239
Avg rating:3.0/5.0
Slides: 51
Provided by: KevinH200
Category:

less

Transcript and Presenter's Notes

Title: Hume: a Domain-Specific Language for Programming with Bounded Resource


1
Hume a Domain-Specific Language for Programming
with Bounded Resource
  • Kevin Hammond, Pedro Vasconcelos, Sun Meng, Roy
    Dyckhoff,Leonid TimochoukUniversity of St
    Andrews, ScotlandGreg Michaelson, Andy
    Wallace,Robert Pointon, Graeme McHale, Chunxiu
    LiuHeriot-Watt University, ScotlandJocelyn
    Sérot, Norman ScaifeLASMEA, Clermont-Ferrand,
    France
  • Martin Hofmann, Hans-Wolfgang LoidlLudwig-Maximil
    ians Universität, München, Germany
  • Christian Ferdinand, Reinhold HeckmannAbsInt
    GmbH, Saarbrücken, Germany
  • http//www.hume-lang.org

2
Scotland
Speyside
Highlands
  • St Andrews, 1411

Glasgow, 1452
Lowlands
Edinburgh, C18th
3
HumeHigher-order Uniform Meta-Environment
David HumeScottish Enlightenment Philosopher
and Sceptic 1711-1776
4
Funded by
1.3M grant under EU Framework VI EmBounded
IST-2004-510255, 2005-2008 200K grants from
the UKs EPSRC Cost modelling for
resource-bounded systems, 2002-2005 MetaHume
EP/C001346/0, 2005-2008 Travel grants from the
British Council, CNRS etc.
EmBounded
5
Hume Research Objectives
  • Real-Time, Hard Space Functional Programming
  • Virtual Testbed for Space/Time Cost Modelling
  • Generative, Domain-Specific Language Design

6
Overview
  1. Hume Language Design and Examples
  2. Stack and Heap Usage for Primitive Recursive
    Programs
  3. Cost Model
  4. Inference Algorithm (Type-and-Effect System)
  5. Results of the Analysis
  6. Conclusions and Further Work

7
Hume Design Domain (1)
8
Hume Design Domain (2)
9
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 ...

10
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

11
A New Direction?
12
Hume Design Objectives
Reliability,Expressibility,Controllability,Pred
ictability,Costability
  • 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

13
FSA-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) -gt
(expr11, ..., expr1m) ... (pattn1, ...,
pattnk) -gt (expr11, ..., exprnm)
14
Hume Language Structure
inport1
  • 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
outport1
outport2
15
Hume Language Structure
  • Declaration Metaprogramming Layer

Coordination Layer
Expression Layer
16
Expression 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 lt expr1,
, exprn gt -- 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)
17
Example Parity Checker
  • type Bit word 1
  • type Parity boolean
  • parity true (true,true)
  • parity false (false,false)
  • box even_parity2
  • in (bBit, pParity)
  • out (showstring, p'Parity)
  • match
  • (0,true) -gt parity true
  • (1,true) -gt parity false
  • (0,false) -gt parity false
  • (1,false) -gt parity true
  • wire even_parity2 (comm1, even_parity2.p'
    initially true) (comm2,
    even_parity2.p)

comm1
b
p (true,)
even_parity2
p
comm2
18
Hume Language Levels
  • Full Hume
  • recursive functions
  • recursive data structures
  • PR-Hume
  • primitive-recursive functions
  • primitive-recursive data structures
  • HO-Hume
  • higher-order non-recursive functions
  • non-recursive data structures
  • FSM-Hume
  • 1st-order non-recursive functions
  • non-recursive data structures
  • HW-Hume
  • no functions
  • non-recursive data structures

Full Hume
PR-Hume
HO-Hume
FSM-Hume
HW-Hume
19
Metaprogramming Example Fair Merge
sysin1
sysin2
  • template merge
  • in (in1 int 32, in2 int 32)
  • out (o int 32)
  • fair
  • (x,) -gt x
  • (,y) -gt y
  • instantiate merge as m 2
  • wire M(b,inp1,inp2,outp) b (in1, in2) (outp)
  • wire M(m1, sysin1, sysin2, m2.in1)
  • wire M(m2, m1.o, sysin3, sysout)

in1
in2
sysin3
m1
o
in2
in1
m2
o
sysout
20
Exception Handling
box box boxid in ins out
outs handles exnids ( match fair )
matches handle handlers
  • 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 "-gt" cexpr
21
Exception Handling Example
  • f n ...
  • box overflow
  • in (c char)
  • out (v string 29)
  • handles TimeOut, HeapOverflow
  • match
  • n -gt f n within 100us within 10KB heap
  • handle TimeOut x -gt Timed Out " show x
  • HeapOverflow x -gt Heap Overflow "
    show x

c
overflow
v
22
Research 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

23
Predicting the Cost
  • ?

24
A Type-and-EffectSpace Cost Model
  • Relates language structure to ltheap, max stackgt
    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
Stack Heap
Derived from theoretical work on cost analysis
for parallel programs
25
Sized Types
10 Nat10 6,1,2 Nat6 3
  • 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

26
Latent Costs
  • Define costs for functions
  • Allow costs to be captured for higher-order
    functions

27
Types and Effects for Stack/Heap Usage
  • Size/Cost Expressions
  • Types and Effects

28
Cost Rules Basic Expressions
29
Cost Rules Conditionals/Cases
30
Cost RulesFunction Applications
31
Cost Rules Function Decls
32
Cost 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

33
Cost 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

34
Solving 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

35
Example Length
  • For the recursive length function
  • length 0
  • length (xxs) 1 length xs
  • The type inferred is
  • length t7x21-x19,x20-gtnatx27,
    x19 gt76x21, x20 gt24x21,x27gtx21

stack,heap
36
Example Take
  • For the recursive take function
  • take n
  • take n (x xs) if n gt 0 then (x take (n-1)
    xs) else
  • The type inferred is
  • take natx53-x51,x52-gtt118x56
    -x54,x55-gtt118x62, x51gt0,x52gt0,x54gt10
    9min(x53,x56), x55gt713min(x53,x56),x62gtmin
    (x53,x56)

37
Example Twice/Map
  • For the Higher-Order twice and map2 functions
  • twice f x f (f x)
  • map2 f
  • map2 f (x) f x
  • map2 f (x(y)) f x,f y
  • add1 x 1x
  • h x map2 (twice add1) x
  • The types inferred are
  • twice (t21-x14,x15-gtt21)-x2,x3-gtt21-x4,x5
    -gtt21,
  • x2gt0,x3gt0,x4gt6max(1x14,1),x5gtx15x15
  • map1 (t54-x62,x63-gtt73)-x45,x46-gtt54x6
    4
  • -x47,x48-gtt73x6
    5,
  • x45gt0,x46gt0,x47gt6max(1max(1x62,1),2),
  • x48gtmax(8x63,3),x65gt1
  • add1 int-x23,x24-gtint, x23gt7,x24gt4
  • h intx112-x75,x76-gtintx113, x75gt3
    0,x76gt25,x113gt1

38
Results
  • !

39
Results
function heap (est) stack(est) heap(GHC
-O2) length 10 181(181) 72(72)
1632length 100 1711(1711)
612(612) 2357 length 1000 17011(17011)
6012(6012) 15630length 10000 170011(170011)
60012(60012) 141626 reverse 10
381(381) 88(98) 2080reverse 100
26862(26862) 810(813) 35395 reverse
1000 2518512(2518512) 8008(8013) 3051874 twice
/map2 1 25(25) 30(30)
1564 twice/map2 2 38(38) 30(30)
1592 lift 129(144) 89(89) --
40
Results (Pump)
2.6KBv. 2.4KB
  • Cost model applied to mine drainage example
  • implemented in prototype Hume abstract machine
    compiler
  • compared with measured dynamic runtime costs

9
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
41
The Reality
  • !!

42
RTLinux Memory Usage (Pump)
Module Size Used by hume_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
text data bss dec
hex filename 30146 52 30048 60246
eb56 hume_module.o
43
Vehicle Sim. Statistics
Thu Aug 21 190606 BST 2003 Box
Statistics control MAXRT 53120ns, TOT
1960041024ns, MAXHP 57, MAXSP 36 env
MAXRT 9101600ns, TOT 1580087776ns, MAXHP
49099, MAXSP 129 vehicle 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 ...
44
Vehicle Sim. Statistics (2)
Wire Statistics control.0 MAX DELAY 24544ns,
MAXHP 47 env.0 MAX DELAY 67072ns, MAXHP
11 vehicle.0 MAX DELAY 33056ns, MAXHP
47 vehicle.1 MAX DELAY 32448ns, MAXHP
2 vehicle.2 MAX DELAY 9118688ns, MAXHP
11 vehicle.3 MAX DELAY 9135968ns, MAXHP
2 Total heap usage 197022 (199078 est) Total
stack usage 597 (640 est) Sat Aug 23 064619
BST 2003
45
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

46
Conclusions
  • 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

47
Further 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)

48
Recent Papers
  • Inferring Costs for Recursive, Polymorphic and
    Higher-Order Functional Programs
  • Pedro Vasconcelos and Kevin Hammond
  • To 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 Systems
  • Kevin Hammond and Greg Michaelson
  • Proc. 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 Automata
  • Greg Michaelson, Kevin Hammond and Jocelyn Sérot
  • Proc. 2004 ACM Symp. on Applied Computing (SAC
    04), Nicosia, Cyprus, March 2004
  • The Design of Hume
  • Kevin Hammond
  • Invited chapter in Domain-Specific Program
    Generation,
  • Springer-Verlag LNCS State-of-the-art Survey, C.
    Lengauer (ed.), 2004

49
http//www.hume-lang.org
50
HumeHigher-order Uniform Meta-Environment
David HumeScottish Enlightenment Philosopher
and Sceptic 1711-1776
Write a Comment
User Comments (0)
About PowerShow.com