Building up to Macroprogramming: An Intermediate Language for Sensor Networks

1. Building up to Macroprogramming:An Intermediate Language for Sensor Networks Ryan Newton, Arvind (MIT), and Matt Welsh (Harvard) @ IPSN 2005 (IEEE Int�l Conf on Information Processing in Sensor Networks)

2. Programming Sensor Networks Difficult Highly distributed system Stringent resource constraint Energy-efficiency is mandatory in every application nesC: de-facto standard language Low level Everything is mixed: Computation, Concurrency, Communication, Efficiency Far too difficult for end-users to make programs Not experts in programming ? Necessity for software support fundamental background Consciousness shared in the research area of sensor network sensornet??????????????????????? fundamental background Consciousness shared in the research area of sensor network sensornet???????????????????????

3. Previous Approach Query engines: Sensornet as a database TinyDB, COUGAR, � Simple but limited use High-level programming abstraction Abstract Regions, Hood, EnviroTrack, � Neighborhood-based programming primitives and operations on them For specific types of application: target tracking Programming toolkit SNACK Reusable service library and compiler Targeting general mechanism: not very easy to use Virtual machine Mat� VM architecture + Intermediate code (cf. Java bytecode) For efficient reprogramming Similar approach, different objectives (discussed later) Built-in operations in AR: - Neighborhood discovery Initialize, may or may not be done continuously - Enumeration Get set of nodes in the region - Data sharing "Get" and "Put": tuple-space-like programming model - Reduction Reduce a shared variable across nodes in the region using the indicated associative operator (sum, max,...)Built-in operations in AR: - Neighborhood discovery Initialize, may or may not be done continuously - Enumeration Get set of nodes in the region - Data sharing "Get" and "Put": tuple-space-like programming model - Reduction Reduce a shared variable across nodes in the region using the indicated associative operator (sum, max,...)

4. �Macroprogramming� Program sensornet as a whole Easier than programming at the level of individual nodes e.g) Matrix multiplication Matrix notation vs. Parallel program in MPI Compile into node-level programs �Regiment� [Newton & Welsh, 2004] Purely functional macroprogramming language for sensornet Example: tracking moving vehicle They used to write the behavior of each node to achieve some global behavior. In macroprogramming, they take the opposite approach to write global behavior and node-level behavior is automatically generated. Macroprogramming????????????high level abstraction?????low level?TinyOS component?map???????? ???scratch??????????????????high level?intermediate lang????????lang?map?????????????? DTM????distributed model???simplified architecture???to TML????(global->distributed)?????????? TML??????gradient???????????end-user????????high level lang designer????? Abstract Regions?????AR?region????????????macroprogramming???????????????? ? ????node-level???????global????? Mate?????? �providing platform for higher-level language�??????????? Mate?virtual machine????????????????TML?compiled intermediate lang????????(?) region stream?set of nodes???????They used to write the behavior of each node to achieve some global behavior. In macroprogramming, they take the opposite approach to write global behavior and node-level behavior is automatically generated. Macroprogramming????????????high level abstraction?????low level?TinyOS component?map???????? ???scratch??????????????????high level?intermediate lang????????lang?map?????????????? DTM????distributed model???simplified architecture???to TML????(global->distributed)?????????? TML??????gradient???????????end-user????????high level lang designer????? Abstract Regions?????AR?region????????????macroprogramming???????????????? ? ????node-level???????global????? Mate?????? �providing platform for higher-level language�??????????? Mate?virtual machine????????????????TML?compiled intermediate lang????????(?) region stream?set of nodes???????

5. Need for Intermediate Langugage Problem arisen in Regiment Compilation is difficult Large semantic gap between Regiment and nesC Solution: Intermediate Language Benefit: Common abstraction for high-level abstractions Reducing complexity for building compiler Direct motivation is from making a compiler for Regiment �Without one, we must build monolithic implementations with nesC� Direct motivation is from making a compiler for Regiment �Without one, we must build monolithic implementations with nesC�

6. Requirements for Intermediate Language Simplicity: Abstract away the details of Concurrency Communication Expressivity: Capture enough details To permit extensive optimizations by compiler They need to satisfy ambivalent requirements: simplicity and expressivity. Need to be simple enough so that high-level lang designer are not bothered by too much details about concurrency and communication etc. Need to be expressive enough to capture enough details to permit optimization during compilation from IL to TinyOS componentThey need to satisfy ambivalent requirements: simplicity and expressivity. Need to be simple enough so that high-level lang designer are not bothered by too much details about concurrency and communication etc. Need to be expressive enough to capture enough details to permit optimization during compilation from IL to TinyOS component

7. Goals Define an intermediate language that Provides simple and versatile abstractions for Communication Data dissemination Remote execution Constitutes a framework for network coordination That can be used to implement sophisticated algorithms: Leader election Group maintenance In-network aggregation Note: Use by human is not a goal But it turns out to be usable as a result Wrap-up of what they tried to address in this paper: (??)????????? Mate?communication abstraction????????????TML?token???????????????????????? They claim that Mate is not providing a good communication abstraction, and it seems they are stressing it by using token.Wrap-up of what they tried to address in this paper: (??)????????? Mate?communication abstraction????????????TML?token???????????????????????? They claim that Mate is not providing a good communication abstraction, and it seems they are stressing it by using token.

8. Outline Background & Motivation Macroprogramming Need for intermediate language Requirements & goals Distributed Token Machines (DTM) Model Token Machine Language (TML) Examples Evaluation / Conclusion / Future Works Discussion

9. DTM (Distributed Token Machines) Model Token-based Execution and Communication model that structures: Concurrency Communication Storage Features Atomic execution Simplify consistency issue Bounded-time completion Enable precise scheduling Simple model What can we say about DTM, comparing to Mate VM?Simple model What can we say about DTM, comparing to Mate VM?

10. DTM Model Players Token Token Message Token name + Payload Form of token on the network Token Object Token + Fixed-size private memory Only accessed by associated token handler Sensor node Scheduler Dispatch Token Message to Token Handlers Token Handler Executed upon receiving Token Message Shared Memory Shared among token handlers Token Store Storing token objects Sole place for dynamic memory allocation When creating token objects

11. How DTM Works Scheduler receives Token Message Scheduler directs Token Message to corresponding Token Handler Token Handler picks corresponding Token Object from Token Store If none, create and initialize one Token Handler consumes the message payload and executes atomically Possibly read/write Token Object�s private memory and node�s shared memory Programming?Token Handlers� behavior??????????????????Programming?Token Handlers� behavior??????????????????

12. Token Handler Interfaces schedule(Ti, priority, data...) / timed_schedule(...) Insert a new Token Message in a nodes� local scheduling queue �timed_...� will be executed precisely after the specified time bcast(Ti, data...) Broadcast a Token Message to the radio neighbors No ACK is_scheduled(Ti) / deschedule(Ti) Query/removal of Token Messages waiting in the scheduler present(Ti) / evict(Ti) Interface into the nodes� Token Store as a whole Query/remove of Token Objects to/from local node�s Token Store How can we write the behavior of Token Handlers? Token Handler?????????????? Programming of DTM is all about describing the behavior of each token handler.How can we write the behavior of Token Handlers? Token Handler?????????????? Programming of DTM is all about describing the behavior of each token handler.

13. Outline Background & Motivation Macroprogramming Need for intermediate language Requirements & goals Distributed Token Machines (DTM) Model Token Machine Language (TML) Examples Evaluation / Conclusion / Future Works Discussion

14. Token Machine Language (TML) Realization of DTM model DTM provides an execution model TML fills in Set of basic operators: Concrete syntax for describing Token Handlers Goals of TML Lightweight Otherwise, compilation from high-level lang to TML will be complex Efficiently mapped onto TinyOS etc. Different semantics: Event-driven Otherwise, compiled executable will not be practically usable Versatile Applicability to wide range of systems Because TML aims to be a common abstract layer Mask the complexity Because it is the fundamental reason for intermediate language ... as opposed to �portability� and �safety� in JVM etc. high level lang?TinyOS????common abstraction layer????intermediate lang???? �?????????high->inter?compile??? �inter->low?compile??????????????????executable?????? �common abst layer??????wide range of system???????? �inter?????????low???????????? Since TML is an intermediate lang that works as a common abstraction layer bridging high-level lang and TinyOS, Compilation from high-level to TML would be complex if it has a huge specification Executable would be unusable if compilation to TinyOS component cannot be done efficiently Need to accommodate wide range of systems Complexity of low level lang should be hidden inside, because it is the first motivation to make intermediate langhigh level lang?TinyOS????common abstraction layer????intermediate lang???? �?????????high->inter?compile??? �inter->low?compile??????????????????executable?????? �common abst layer??????wide range of system???????? �inter?????????low???????????? Since TML is an intermediate lang that works as a common abstraction layer bridging high-level lang and TinyOS, Compilation from high-level to TML would be complex if it has a huge specification Executable would be unusable if compilation to TinyOS component cannot be done efficiently Need to accommodate wide range of systems Complexity of low level lang should be hidden inside, because it is the first motivation to make intermediate lang

15. TML Features Subset of C, extended with DTM interfaces Without data pointer No invalid memory reference Only fixed length loops Completion in bounded time Sole procedure call: �Scheduling of token� Compiled to nesC code Guarantee conformance to DTM execution semantics Buildup of abstraction Enriched by adding features (example follows next) �DTM execution semantics�: - handlers will terminate - programs will not crash motes - invalid memory references are impossible (due to the lack of pointers) Buildup of abstraction: Explained in Figure 2. In short, not only �compiling down� high-level lang to TML, they also �build up� generic features on TML. Fig.2????????high->TML?compile (�compile down�)???????????????????TML????�build up�??????????????????????subroutine call???????gradient????????? �DTM execution semantics�: - handlers will terminate - programs will not crash motes - invalid memory references are impossible (due to the lack of pointers) Buildup of abstraction: Explained in Figure 2. In short, not only �compiling down� high-level lang to TML, they also �build up� generic features on TML. Fig.2????????high->TML?compile (�compile down�)???????????????????TML????�build up�??????????????????????subroutine call???????gradient?????????

16. Building up Features: Subroutine Calls Subroutine calls NOT preferred by system For small and fast atomic actions Execution time could be unpredictable Introduce call-stack: another dynamic structure Preferred by users For simplicity Solution: CPS transformation CPS: Continuation Passing Style As one of the examples of building up features on TML, they bring up subroutine callsAs one of the examples of building up features on TML, they bring up subroutine calls

17. CPS Transformation Automatically generated Systematic conversion in TML, but difficult in nesC # Codes are modified from the ones in the paper that contained several errors scheduled commands� order preserved (by spec of scheduler) Straightforward conversion in TML, but difficult in nesC intermediate lang??????????benefit???????? Allowing this kind of conversion is one of the benefits of introducing an intermediate language.# Codes are modified from the ones in the paper that contained several errors scheduled commands� order preserved (by spec of scheduler) Straightforward conversion in TML, but difficult in nesC intermediate lang??????????benefit???????? Allowing this kind of conversion is one of the benefits of introducing an intermediate language.

18. Building up Features: Blocking Operation Split-phase ? Blocking Operation Split-phase TinyOS operations Expose them as blocking operations Using CPS transformation, as in �subcall� case Another example of adding features P.5 left mid Split-phase makes programming complex and harder to understand Another example of adding features P.5 left mid Split-phase makes programming complex and harder to understand

19. Outline Background & Motivation Macroprogramming Need for intermediate language Requirements & goals Distributed Token Machines (DTM) Model Token Machine Language (TML) Examples Evaluation / Conclusion / Future Works Discussion

20. Examples Building up Features: Adding �gradient� interface TML examples Timed data gathering Distributed event detection Leader election Intermediate Lang for Macroprogramming Compiling Regiment

21. Example: Adding �Gradient� Interface �Gradient� General purpose mechanism for breadth-first exploration from a source node Establish a spanning tree that tells all nodes within the gradient how to route to the source as well as their hop-count Used in �Directed Diffusion� Interfaces (to Scheduler) gemit(Ti, data...) Begins gradient propagation (cf. bcast) grelay(Ti, data...) Continues gradient propagation (cf. bcast) greturn(Tcall, Tvia, Taggr, data...) Propagate data up to their roots Via the gradient specified by Tvia Fires Tcall token handler on the data when it reaches the root With optional aggregation (Taggr) dist(Ti) / version(Ti) Get info about neighbors (in terms of gradient) Talk briefly about directed diffusion ??gradient?library?????????????????????Mate???????????????? greturn?????source?????base station? node? DD??base station?sink????node?source???? ? ????base station???? Talk briefly about directed diffusion ??gradient?library?????????????????????Mate???????????????? greturn?????source?????base station? node? DD??base station?sink????node?source???? ? ????base station????

22. Example: Timed Data Gathering Sample each node�s light sensor every sec Routing tree is refreshed every 10 secs

23. Example: Distributed Event Detection Alarm is raised when a quorum of sensors detect an event Assuming unreliable sensors Every node spread two-hop gradient when it detects an event Not going into details ---- EventDetected token????????????? timed_call?timed_schedule??????? EventDetected ???node?AddActivation????? ??????AddActivation?schedule AddActivation ????dist?2????AddActivation?relay total_activation???? total?threshold?????base station??? 1500msec?????????SubActivation?schedule SubActivation total???? total?0????????schedule????Add/Sub?????--???????Not going into details ---- EventDetected token????????????? timed_call?timed_schedule??????? EventDetected ???node?AddActivation????? ??????AddActivation?schedule AddActivation ????dist?2????AddActivation?relay total_activation???? total?threshold?????base station??? 1500msec?????????SubActivation?schedule SubActivation total???? total?0????????schedule????Add/Sub?????--???????

24. Example: Leader Election Although they give several examples of TML codes, their initial goal was an intermediate language and direct use by human was not intended. However, what they claim is that TML is simple enough for programmers to write. ????????????TML?????????????????goal??????????? ? ??????????????????????????????????????????????Although they give several examples of TML codes, their initial goal was an intermediate language and direct use by human was not intended. However, what they claim is that TML is simple enough for programmers to write. ????????????TML?????????????????goal??????????? ? ??????????????????????????????????????????????

25. Example: Compiling Regiment Tokens membership Defines a region Node holding a membership token is a member of region at that time formation Initiate the work of constructing / discovering the region Have constraints on where and when they need to fire Translate region-logic to token-logic Rather straightforward �Let region be a set of nodes satisfying criteria of .....� �Give membership token to a set of nodes satisfying ...� Initial motivation of designing DTM model and TML TML helps bridge this semantic gap by virtue of token-holders forming natural groups. Every expression in a Regiment program which evaluates to a region value gets assigned a formation token and a membership token. Every node that holds the membership token at a particular time is a member of region at that time. Formation tokens on the other hand, initiate the work of constructing or discovering the region. Formation tokens also have constraints on where and when they need to fire. Because of Regiment�s clear, high-level semantics we can reason about where and when all of these events need to take place. Once this is done, TML makes it straight-forward to translate region-logic into token-logic. ?????????set of nodes?region???????????????????set of nodes?token????????????????? Initial motivation of designing DTM model and TML TML helps bridge this semantic gap by virtue of token-holders forming natural groups. Every expression in a Regiment program which evaluates to a region value gets assigned a formation token and a membership token. Every node that holds the membership token at a particular time is a member of region at that time. Formation tokens on the other hand, initiate the work of constructing or discovering the region. Formation tokens also have constraints on where and when they need to fire. Because of Regiment�s clear, high-level semantics we can reason about where and when all of these events need to take place. Once this is done, TML makes it straight-forward to translate region-logic into token-logic. ?????????set of nodes?region???????????????????set of nodes?token?????????????????

26. Outline Background & Motivation Macroprogramming Need for intermediate language Requirements & goals Distributed Token Machines (DTM) Model Token Machine Language (TML) Examples Evaluation / Conclusion / Future Works Discussion

27. Evaluation Current implementation High-level simulator Compiler targeting nesC/TinyOS environment Comparison with native TinyOS code Code size: Very good RAM, CPU usage: Bad Overhead of running scheduler Unnecessary copying of buffers By excluding pointers High level simulator?????????High level simulator?????????

28. Conclusion / Findings Atomic action model of concurrency is good because ... Preclude deadlocks Easy reasoning about timing Communication bound to persistent storage (= tokens) is good because ... Give a way to refer to communications that have happened through the token they leave behind ???debug??????????????????????debug???????????????????

29. Future Directions Dynamic retasking As in Mat�: Support Mat�s view: �Separate representations for End-user programming model Code transport layer Execution engine� TML code should be compiled into Mat� bytecode Focus on whole-program compilation Numerous optimizations depend on whole program optimization Impossible in Mat� architecture (Bytecode + VM) Incorporate token-based algorithms Routing, Consensus,... TML code?Mate bytecode????????????? Mate??????high level code ? TML code ? executable ? transport Mate?????high level code ? TML code ? Mate bytecode ? transport (Mate�s mechanism) ? execute on interpreter transport??????????????(Dynamic retasking??????????????) whole program compilation????????? ? program??????????(bytecode + VM?????)?optimization?????????TML code?Mate bytecode????????????? Mate??????high level code ? TML code ? executable ? transport Mate?????high level code ? TML code ? Mate bytecode ? transport (Mate�s mechanism) ? execute on interpreter transport??????????????(Dynamic retasking??????????????) whole program compilation????????? ? program??????????(bytecode + VM?????)?optimization?????????

30. Discussion Is DTM model enough capable? To describe every mode of execution at each node Is token an appropriate abstraction? How is it different from messages as in MPI? TML: explicit association between message and object Is TML Versatile enough? Is macroprogramming a viable approach? Easy? Expressive? Extensible? Flexible? What is missing? Refinement of code for further optimization (by hand)? gradient?build up???????????????????TML?????????????????????????????????? ????component??????????????????????????????? gradient?build up???????????????????TML?????????????????????????????????? ????component???????????????????????????????

31. References nesC: David Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric Brewer, and David Culler , "The nesC Language: A Holistic Approach to Network Embedded Systems" [citeseer], PLDI, 2003 TinyOS: Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler and Kristofer Pister, �System architecture directions for network sensors� ASPLOS-IX, 2000 Mat�/ASVM: Philip Levis and David Culler, "Mat�: A Tiny Virtual Machine for Sensor Networks." ASPLOS-X, 2002 Philip Levis, David Gay, and David Culler, "Active Sensor Networks�, NSDI, 2005 Abstract Regions Matt Welsh and Geoff Mainland , "Programming Sensor Networks Using Abstract Regions" [slides], NSDI, 2004 Regiment Ryan Newton and Matt Welsh, �Region Streams: Functional Macroprogramming for Sensor Networks�, DMSN, 2004 Directed Diffusion Chalermek Intanagonwiwat, Ramesh Govindan and Deborah Estrin, �Directed diffusion: A scalable and robust communication paradigm for sensor networks�, MobiCOM, 2000 TinyDB: Samuel R. Madden, Mehul A. Shah, Joseph M. Hellerstein, and Vijayshankar Raman, �Continuously Adaptive Continuous Queries over Streams�, SIGMOD, 2002 COUGAR Philippe Bonnet, J. E. Gehrke, and Praveen Seshadri, �Querying the Physical World�. IEEE Personal Communications, Vol. 7, No. 5, October 2000, pages 10-15 SNACK Ben Greenstein, Eddie Kohler, and Deborah Estrin, �A Sensor Network Application Construction Kit (SNACK)�, SenSys, 2004

32. BACKUP SLIDES FROM HERE

33. TML Unified abstraction for Communication Token is the only method of communication Execution Token Handler is the only place of execution Network state management Token Objects and Shared Memory ????????????????????????????????????????????????

34. Subtoken Indexed token object All subtokens share a single token handler for efficiency cf) component parameterization in nesC cf2) Can be seen as �multiple instances (=subtoken) of token class� ????????????????????????

35. nesC C-based language Component-oriented component with bidirectional interface Event-based execution model Concurrency model with extensive compile-time analysis �Asynchronous code� / �Synchronous code� �Split-phase operations� No blocking operations: Request / Completion

36. TinyOS Implemented by nesC Event-based programming model Set of components Rather than monolithic OS Abstract hardware Layering of components: �Command� and �Event� Services provided such as: RF messaging Periodic timer events Asynchronous access to UART data transfers Mechanism for static, persistent storage http://e-words.jp/w/UART.html UART ??? : ????? ????? : Universal Asynchronous Receiver Transmitter ???????????????????????????????????????????????????????????????????????????????????????????????PC??16550????????????????????????http://e-words.jp/w/UART.html UART ??? : ????? ????? : Universal Asynchronous Receiver Transmitter ???????????????????????????????????????????????????????????????????????????????????????????????PC??16550????????????????????????

37. Abstract Regions Efficient communication primitives Provide interface for Neighborhood discovery Initialize, may or may not be done continuously Enumeration Get set of nodes in the region Data sharing "Get" and "Put": tuple-space-like programming model Reduction Reduce a shared variable across nodes in the region using the indicated associative operator (sum, max,...) Allow tuning the trade-off between accuracy and resource usage By exposing low level tuning parameters: #retransmission, timeout interval...

38. Directed Diffusion Communication abstraction for Data-centric dissemination Sink (base-station) publishes �interests� Source (sensor) publishes �event� Propagation is facilitated when gradient is large Reinforcement-based adaptation Successful paths are reinforced Realizes energy-efficient & robust dissemination Directed diffusion is a novel data-centric, data disemmination paradigm for sensor networks. Directed diffusion has some novel features: data-centric dissemination, reinforcement-based adaptation to the empirically best path, and in-network data aggregation and caching. These features can enable highly energy-efficient and robust dissemination in dynamic sensor networks, while at the same time minimizing the per-node configuration that is characteristic of today's networks. ???????reinforce???????? sink???????????????path?????????? ? yes. source??????????????Directed diffusion is a novel data-centric, data disemmination paradigm for sensor networks. Directed diffusion has some novel features: data-centric dissemination, reinforcement-based adaptation to the empirically best path, and in-network data aggregation and caching. These features can enable highly energy-efficient and robust dissemination in dynamic sensor networks, while at the same time minimizing the per-node configuration that is characteristic of today's networks. ???????reinforce???????? sink???????????????path?????????? ? yes. source??????????????

39. Mat� / ASVM Application specific virtual machine To cope with different programming models for different application classes Complete generality is not necessary for a given network Mainly for Efficient dynamic reprogramming Safety (NOT for portability as in JVM) Expose new programming primitives by Using application-specific opcodes Motivation??reprogramming???binary?????communication??????????????????????????????????? Andrew????????????retasking???????????????????????????? ASVM addresses three of Mat�s main limitations: flexibility, concurrency, and propagation. (Active Sensor Networks??) ????????/?????????????????? Based on the assumption that �Complete generality is not necessary ....�Motivation??reprogramming???binary?????communication??????????????????????????????????? Andrew????????????retasking???????????????????????????? ASVM addresses three of Mat�s main limitations: flexibility, concurrency, and propagation. (Active Sensor Networks??) ????????/?????????????????? Based on the assumption that �Complete generality is not necessary ....�

40. Mat� Build Process From "Rapid and Safe Programming of In-situ Sensor Networks."Qualifying examination proposal, Jan 2004. http://www.cs.berkeley.edu/~pal/talks/quals.pdf p.15 Users select three things � A scripting language � A set of library functions � A set of events that trigger execution Mat� builds a VM and scripting environment � Instruction set customized for deployment � VM provides needed services: routing, code propagation � Scripts compile to custom instruction set � VM automatically distributes new programs VM and scripter form an application-specific runtime From "Rapid and Safe Programming of In-situ Sensor Networks."Qualifying examination proposal, Jan 2004. http://www.cs.berkeley.edu/~pal/talks/quals.pdf p.15 Users select three things � A scripting language � A set of library functions � A set of events that trigger execution Mat� builds a VM and scripting environment � Instruction set customized for deployment � VM provides needed services: routing, code propagation � Scripts compile to custom instruction set � VM automatically distributes new programs VM and scripter form an application-specific runtime

41. Mat� / ASVM Features Customizable virtual machine framework Event-driven, thread-based, stack architecture Customizable execution events and instruction set Users select three things A scripting language A set of library functions A set of events that trigger execution Mat� builds a VM and scripting environment Instruction set customized for deployment VM provides needed services: routing, code propagation Scripts compile to custom instruction set VM automatically distributes new programs VM and scripter form an application-specific runtime

42. TML vs. Mat� (According to TML paper) Mat� ... provides only low-level radio communication directly within Mat�, and uses application-specific opcodes � essentially a foreign function interface into other TinyOS components � to expose new communication primitives such as abstract regions. In contrast, TML provides a coordinated communication and execution architecture, based on tokens, that is used to build up new communication abstractions. Ideally, the user program should be compiled to a concise bytecode supported by a pre-installed virtual machine. We will look into targetting a virtual machine rather than native code, perhaps Mat� itself. In short, TML can be used on top of Mat� ?????????Mate?execution model????????communication?????low level????????????????????communication abstraction??????????????????????????Mate?execution model????????communication?????low level????????????????????communication abstraction?????????????????

43. Regiment Purely functional macroprogramming language No direct manipulation of program state High-level program manipulates �regions� of sensor data as values Individual nodes appear as data streams Regions are groupings of these streams Designated using a number of different criteria Program operates over these streams and regions translated into node-level actions Example: Tracking Object