CIL Tools for TinyOS

CIL Tools for TinyOS

Software Tools for Sensor Networks
School of Computing
University of Utah

CIL Executables

This table contains links to various executables for working with our modified version of CIL. We provide these for those interested in our tools but not willing to commit to downloading all of our modified CIL source and building it themselves. We use these executables as source-to-source translators for C.

native avr msp430 8051 (highly experimental)
Linux exe exe exe exe
Cygwin exe exe exe exe

Wrapper perl scripts

Using the modified CIL executables above can be a bit overwhelming because of the numerous command-line options (run with --help to see them all). We also provide some wrapper scripts (in perl) that hide most of the options and expose only those most necessary for running specific tasks. You can download the scripts below.

Script Description
utah-inliner Will Archer built an inliner for C programs using CIL. It has two primary methods of inlining. The auto-inliner blindly follows inline directives placed in the code. The smart-inliner inlines according to our tuned heuristics. The heuristic is tuned to work on TinyOS 1.x code in tandem with cXprop and we have not analyzed its effectiveness on TinyOS 2.x code yet.
utah-cleaner Nathan Cooprider built a not-so-clever cleaner for C code using CIL. It executes several peep-hole optimizations in addition to copy-propagation and a whole-program dead variable elimination. This transformation iterates until it reaches a fixed-point. This can be used by the inliner and is used by cXprop before and after cXprop proper runs.
utah-splitter Nathan Cooprider built a transformation which splits global structs. It is conservative in how it does this. For example, no address-taken structs are split. There is an option to allow it to attempt the splitting of volatile structs. The main purpose of this pass is to prep the code for greater RAM compression by CComp.
utah-cXprop cXprop is a whole program analyzer and optimizer for C code. It combines dataflow analyis, alias analysis, callgraph generation, and concurrency analysis into a single analysis. This allows the different pieces to interact and learn from each other. cXprop performs global constant propagation and dead code elimination. It can also print out a program's callgraph.

Official cXprop homepage: http://www.cs.utah.edu/~coop/research/cxprop

CComp CComp uses some header files and scripts which are part of our modified CIL but not captured in the executable. You have to go to its official page in order to get a working copy of CComp. CComp implements offline compression for on-chip RAM. It trades execution time and code memory for more data memory.

Official CComp homepage: http://www.cs.utah.edu/~coop/research/ccomp

Using the scripts

Here is an example of how to use the scripts.
  1. Download the avr executable for the correct machine you are running (either linux or cygwin). Note: The script commans will assume you are running linux from now on. If you are running cygwin, you need to add a --cygwin argument to all the script commands
  2. Download the scripts
  3. Add the location where the executable and the scripts are to your PATH if it is not there already
  4. Download blink.c. This is the app.c file created when I run make mica2 in tinyos-1.x/apps/Blink. It is found in build/mica2 after making the application
  5. Run utah-inliner blink.c to make blink.inlined.c (blink.c with all the functions marked as inline inlined)
  6. Run utah-cleaner blink.c to make blink.clean.c (blink.c which has been cleaned up a bit using our cleaner)
  7. Run utah-cXprop --inline-smart blink.c to make blink.cxproped.c (blink.c inlined, cleaned up, and optimized using cXprop)
  8. Compile all of the source files individually. Probably use something like avr-gcc -mmcu=atmega128 -fdollars-in-identifiers -Os filename.c -o exename.exe
  9. Compare the executables. For example, you could use avr-size *.exe to compare their code and data sizes

Adding tools to TinyOS Make rules

This is not meant to be a step-by-step tutorial of how to modify the make rules of tinyOS to integrate our scripts. Instead, it is meant to give you the general idea and get you most of the way there.

In order to add our scripts to the build process you have to modify the rules file for the platform. This can be found at tinyos-2.x/support/make/avr/avr.rules for the mica2 platform on TinyOS 2. A similar file exists for msp (telosb). In TinyOS 1 it can be found at tinyos-1.x/tools/make/avr/avr.rules (and msp similarly).

You want to modify the exe0 rule. Add the -conly flag and take out the $(LIBS) $(LDFLAGS) to the ncc command. That will change it to create just the app.c file instead of the executable.

Now you want to add a command which process the app.c file using the scripts. You might try something like this utah-cXprop --inline-smart $(BUILDDIR)/app.c

After completing the source-to-source transformation, you have to then build the application. You can use nesC to do this with a command like this $(NCC) -o $(MAIN_EXE) $(OPTFLAGS) $(PFLAGS) $(CFLAGS) $(WIRING_CHECK_FLAGS) $(BUILDDIR)/app.cxproped.c $(LIBS) $(LDFLAGS) -fdollars-in-identifiers Note: when I was testing I had to add that last flag to get it to compile

So, putting all the pieces together it might look something like this:
$(NCC) -o $(MAIN_EXE) $(OPTFLAGS) $(PFLAGS) $(CFLAGS) $(WIRING_CHECK_FLAGS) -conly $(COMPONENT).nc
ifdef WIRING_CHECK_FILE
@nescc-wiring $(WIRING_CHECK_FILE)
endif
utah-cXprop --inline-smart $(BUILDDIR)/app.c
$(NCC) -o $(MAIN_EXE) $(OPTFLAGS) $(PFLAGS) $(CFLAGS) $(WIRING_CHECK_FLAGS) $(BUILDDIR)/app.cxproped.c $(LIBS) $(LDFLAGS) -fdollars-in-identifiers

That added cXprop script to every application build. You can use a similar technique to add the other scripts. Changing the code to make it only use the scripts conditionally is less straightforward but still pretty easy. You want to read the README in the make directory for your version of tinyOS.

Basically, you want to make a new .extra file that sets some environment variables which trigger a change in the avr.rules make instructions. So if the variables in the .extra file are defined then the script gets run, otherwise do the normal build.


Nathan Cooprider <coop@cs.utah.edu>