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.
On Mar 12, 2007, at 10:34 AM, Fabian Scheler wrote:> 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.A gratuitous plug for a recent research project: If you use LLVM, you can also get a compiler called SAFECode that (a) enforces memory safety with very low overhead, and (b) defines a subset of C for which you get memory safety with *no* run-time checks. The latter work was specifically aimed at embedded systems. In fact, we called the language subset "Control C" :^). If you're interested, here are a couple of papers on these issues: (1) "Memory Safety Without Garbage Collection for Embedded Applications" Dinakar Dhurjati, Sumant Kowshik, Vikram Adve and Chris Lattner ACM Transactions in Embedded Computing Systems (TECS), February 2005. http://llvm.org/pubs/2005-02-TECS-SAFECode.html (2) "Enforcing Alias Analysis for Weakly Typed Languages" Dinakar Dhurjati, Sumant Kowshik, and Vikram Adve Technical Report #UIUCDCS-R-2005-2657, Computer Science Dept., Univ. of Illinois, Nov. 2005. http://llvm.org/pubs/2005-11-SAFECodeTR.html SAFECode is a research prototype and so not yet robust, but we aim to make it robust and distribute it publicly. You can get the current version with that caveat. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/
> If you're interested, here are a couple of papers on these issues: > > (1) "Memory Safety Without Garbage Collection for Embedded Applications" > Dinakar Dhurjati, Sumant Kowshik, Vikram Adve and Chris Lattner > ACM Transactions in Embedded Computing Systems (TECS), February 2005. > http://llvm.org/pubs/2005-02-TECS-SAFECode.html > > (2) "Enforcing Alias Analysis for Weakly Typed Languages" > Dinakar Dhurjati, Sumant Kowshik, and Vikram Adve > Technical Report #UIUCDCS-R-2005-2657, Computer Science Dept., Univ. > of Illinois, Nov. 2005. > http://llvm.org/pubs/2005-11-SAFECodeTR.html > > SAFECode is a research prototype and so not yet robust, but we aim to > make it robust and distribute it publicly. You can get the current > version with that caveat.that really looks interesting at first glance, I will definitely have a closer look at it. Thank you :-) Ciao, Fabian
SAFECode sounds very interesting. How can we get our hands on it? On 3/12/07, Vikram S. Adve <vadve at uiuc.edu> wrote:> > > > On Mar 12, 2007, at 10:34 AM, Fabian Scheler wrote: > > > 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. > > > A gratuitous plug for a recent research project: If you use LLVM, you > can also get a compiler called SAFECode that (a) enforces memory > safety with very low overhead, and (b) defines a subset of C for > which you get memory safety with *no* run-time checks. The latter > work was specifically aimed at embedded systems. In fact, we called > the language subset "Control C" :^). > > If you're interested, here are a couple of papers on these issues: > > (1) "Memory Safety Without Garbage Collection for Embedded Applications" > Dinakar Dhurjati, Sumant Kowshik, Vikram Adve and Chris Lattner > ACM Transactions in Embedded Computing Systems (TECS), February 2005. > http://llvm.org/pubs/2005-02-TECS-SAFECode.html > > (2) "Enforcing Alias Analysis for Weakly Typed Languages" > Dinakar Dhurjati, Sumant Kowshik, and Vikram Adve > Technical Report #UIUCDCS-R-2005-2657, Computer Science Dept., Univ. > of Illinois, Nov. 2005. > http://llvm.org/pubs/2005-11-SAFECodeTR.html > > SAFECode is a research prototype and so not yet robust, but we aim to > make it robust and distribute it publicly. You can get the current > version with that caveat. > > --Vikram > http://www.cs.uiuc.edu/~vadve > http://llvm.cs.uiuc.edu/ > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070314/3323dc86/attachment.html>