1 / 50

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

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

edythe
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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-Maximilians Universität, München, Germany Christian Ferdinand, Reinhold HeckmannAbsInt GmbH, Saarbrücken, Germany http://www.hume-lang.org

  2. Scotland St Andrews, 1411 Speyside Highlands 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 UK’s 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 • Hume Language Design and Examples • Stack and Heap Usage for Primitive Recursive Programs • Cost Model • Inference Algorithm (Type-and-Effect System) • Results of the Analysis • 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,Predictability,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) -> (expr11, ..., expr1m)| ...| (pattn1, ..., pattnk) -> (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 < 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)

  17. Example: Parity Checker typeBit = word 1; typeParity = 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 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 template merge in (in1 :: int 32, in2 :: int 32) out (o :: int 32) fair (x,*) -> x | (*,y) -> y; instantiatemerge 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 sysin2 in1 in2 sysin3 m{1} o in1 in2 m{2} 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 "->" cexpr

  21. 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; 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 <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 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 weakenedto 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 Rules:Function 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 (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}

  36. Example: 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)}

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

  38. Results !

  39. Results function heap (est) stack(est) heap(GHC -O2) length: 10181(181) 72(72) 1632length: 100 1711(1711) 612(612) 2357 length: 1000 17011(17011) 6012(6012) 15630length: 10000170011(170011) 60012(60012) 141626 reverse: 10381(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 pump47 38 17 17environ49 47 29 29water54 54 24 24logger119 105 39 31others115 106 70 70wires96 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 19:06:06 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 06:46:19 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 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

  49. http://www.hume-lang.org

  50. HumeHigher-order Uniform Meta-Environment David HumeScottish Enlightenment Philosopher and Sceptic 1711-1776

More Related