[LLVMdev] Expressing inter thread dependencies

Fabian Scheler fabian.scheler at gmail.com
Mon Mar 12 08:34:10 PDT 2007


Hello everybody,

I'm developing a source code transformation system for real-time
systems currently, i.e. I want to map the application (a set of event
handlers) to a run-time or operating system semi-automatically (if
anybody is interested in the background - see below, of course,
comments are welcome there, too ;-)). Therefore, I have to be able to
express dependencies between different event handlers (some
predecessors provide data for a common successor and things like
that). I thought about adding some intrinsic functions for this
purpose. Is this the right way or is there a better solution?

Any comments are welcome!

Ciao, Fabian

Background:

One problem when building real-time systems is the mapping of the
software components making up the application to an underlying
run-time or operating system or even bare metal. In other words: the
application has to be mapped to event handlers that are implemented
with the measures stated before (eg. threads, semaphore, schedule
table scheduler ...). In many cases the properties run-time or
operating systems used imply restrictions on the application or even
modeling level (event handlers never block, are always preemptive
...), a quite famous example for such implications is the discrepancy
between time-triggered (TT) and event-triggered (ET) real-time
systems. Applications developed for TT/ET systems can hardly be
transformed into applications for ET/TT systems or vice versa, because
the control flow abstractions employed in these approaches are very
different.

My idea is to strip as much run-time or operating system dependent
information as possible, and thus, get an almost independent
representation. Well such an independent representation is a global
control-/data-flow graph and some additional information (mutual
exclusion of certain parts of the cfg, and, of course, dependencies
between different event handlers). This representation can then be
mapped to operating systems exposing different properties (eg. tt or
et).

How I came across LLVM? Well, I do not want to target bare metal with
the tool, but some kind of operating system, as the LLVM
infrastructure offers a C-backend I am able to target any operating
system providing a C-API. First I had hacking in GCC in mind, but
after having a more thorough look into the GCC documentation convinced
me not to do this. On the GCC mailing list I got a hint to LLVM when I
asked for a C-backend for GCC. After playing around a bit with LLVM, I
decided to use LLVM, because of its great documentation, its clean and
straight-forward design and it because it seems to be easily
applicable also for beginners.



More information about the llvm-dev mailing list