Areas of work


Study groups



Code generation


Of course, users of the language will want to generate executable code from an actor description, in order to simulate or eventually implement an actor on some target platform. The CAL software infrastructure is designed to make the creation of code generators as simple as possible.

Figure 1: Cal code generation overview.

The general idea is that as much of the work as possible is performed in the source language itself---simplifications, optimizations, checking, annotations that extract static information from the source code, etc. Many of these steps are generically useful, and we are providing a suite of little programs that transform and annotate a simple core data structure. Platform-specific compilers can choose from these modules and eventually add a last step that creates the actual code.

We have defined one particular chain of these transformations that creates a canonical form of an actor (called CalCore) which seems to be useful as the basis for code generation to a number of different platforms.

Figure 2: ActorCore Architecture

In many cases, especially when prototyping code generators, it is possible to generate an adaptor between a generic form of the actor and the platform-specific execution engine, rather than to generate a complete platform-specific actor from scratch. There exists a code generator that produces such a generic actor for the Java platform, called an ActorCore.

Code generation contexts: platforms and profiles

By design, CAL is intended to be usable in a wide variety of application domains -- from general purpose applications (where actors would play a role similar to, say, JavaBeans) to embedded software to hardware. From a programmer's perspective, these environments differ in the kinds of data types they support, the available function libraries, and the kinds of operators. Defining one language for all these domains runs the risk of either falling for the common denominator approach, leading to a language that feels 'too small' for the more liberal platforms, or the risk of designing a common multiple, which will then be difficult to implement on the more constrained platforms.

The solution that we are aiming for is to keep the language itself parametric, i.e. to leave design choices such as type system, operators, and basic functions open, so that special versions of the language may be created for specific platforms. This description, called a context, is itself an XML document -- see this concrete example (which describes the Ptolemy context, and is evolving as we complete our code generation path). It contains information about operators, substitutions, types, etc.

This, of course, means that in general actors will not be portable across platforms, because they make use of properties that are only part of the specific CAL dialect. To an extent, this is in the nature of things -- an actor implementing a GUI component is of little value for describing a piece of silicon. On the other hand, there may very well be actors that would be useful on different platforms, but are not portable because they have been written in different dialects.

In order to provide a framwork for the construction of dialects, we aim at defining language profiles. Such a profile would describe a set of capabilities (data types, operators, library functions) that characterize a particular kind of platform. It serves as a contract between CAL implementors and CAL users (i.e. programmers writing CAL actors) -- implementors of CAL would know which capability to provide, and users would know which to rely on in order to make an actor description portable across all implementations that realize a particular profile.

In addition, we aim at defining a structure among these profiles, not unlike an inheritance hierarchy: if a profile A is a sub-profile of B, then any actor that conforms to profile A will also run on a platform conforming to profile B (and produce equivalent results).


©2002-2018 U.C. Regents