This article presents a project that is part of the ROTOR initiative and is partially funded by Microsoft Research. The final goal of the project is to enable the use of .NET as a cross-development platform for programmed "wearable" devices. In this context, we first present an interoperability framework for distributed hardware objects. We then show how the .NET Shared Source Common Language Infrastructure (SSCLI) has been used to upgrade the C# notion of objects and the C# compiler to support this framework optimally.

With the aim of establishing an experimental simulation and development platform for distributed devices, we have implemented a suitable concept of remote objects in C#, based on ROTOR. Specifically, we have added two new member types of C# objects: activities and channels. Syntactically, both constructs resemble methods without parameters. Semantically, however, they are quite different.

Activities
An activity is a separate thread of control that is launched automatically when the object is created. Its domain of operation is the object state space. An object can have none, one, or more activities associated with it; the activities themselves are responsible for synchronizing properly among themselves and with method calls. Activities defined in an extended class run in parallel with activities defined in the corresponding base class. If an object has no activity, it is called passive. Shared resources are typical examples of passive objects.

Channels
In our context a channel is a vehicle for the support of syntax-controlled dialogues between objects. The idea is that a formal grammar underlies each channel type, thereby acting as a contract between the dialogue partners. A dialogue is then simply an exchange of syntactic tokens under control of the grammar, and both the sender and the receiver incorporate a parser for this grammar. In technical detail, this is what happens when object A intends to communicate with object B:

Note that in our remote object model formal grammars take the role of interfaces. The querying mechanism used is reminiscent of COM and presupposes some obligatory home protocol analogous to the infamous IUnknown interface.

Comparing our channel-based communication model with remote method invocation, we recognize some obvious advantages.
1.   By concept, the sender is not blocked while the recipient is in action.
2.   The state of the dialogue is completely captured by the channel, concerns are decoupled effectively, and programming is simplified considerably, in particular in scenarios with multiple simultaneous dialogue partners.
3.   Tokens are typed implicitly by the underlying grammar and encoded explicitly according to universal rules, a safe precondition for an interoperability scheme that is inherently programming language independent.

Figure 1 shows two active objects, A and B, communicating with each other via channel C. Note that object B is simultaneously carrying out another dialogue with a third object.

The examples in Table 1 are organized in ascending order of complexity and illustrate the versatility of formal grammars. The form of representation used is Extended BNF (Extended Backus-Naur Form). Return message traffic is highlighted in italics.

Mapping the New Constructs
Activities
Because activities are supposed to control a separate thread that is created when the containing object is instantiated, activities declared by the following class A description are mapped into methods with synthetically generated names. In addition, the constructor of A is extended with code to create the new thread(s).

class A {
...
activity {
// activity statements
}
...
}

Channels
Channels are again run as separate threads. However, in contrast to activities, channels are named and instantiated explicitly. As a consequence, multiple instances of the same channel can run simultaneously within the same object.

Let us now assume the following declaration of a channel C within class B:

class B {

...
channel C {
// parser statements
}
}

Then, the mapping of this channel by the compiler results in the following trio of features within B.

Another important aspect of this model is the mapping of the basic channel operations open, close, ! (send token), and ? (receive token), in which the first two occur in the client code only, while the latter two can be used in different variants by both the client and the server, as illustrated by the following code fragments. Token is an auxiliary class defining a universal set of tokens and is contained in a library named System.Channels.

Client code

using System.Channels
...
Token t;
B b = new B();
B.C c = open b.C;
...  c!t; ...  c?t; ... 
... 
Server code

class B {
...
channel C { Token t;
...  ?t; ...; !t; ... 
}
}

The actual mapping of the different constructs outlined above is specified by Table 2.

Note the methodological similarity between the channel accessors and the usual property accessors in the C#. This provides the ability to access channels from foreign languages within .NET.

The two buffers bound to each channel are stored as data slots in the thread descriptor. This allows the use of the "?" and "!" operators without channel reference from anywhere within the channel thread. It also allows the generation of inline code for these operators.

Extending the SSCLI C# Compiler
In order to implement the constructs of activities and channels on the foundation of the SSCLI, it is important to have a good understanding of the C++ code of the C# compiler before applying any changes. After installing the SSCLI sources a full compile with the buildall command is necessary. Later, the build command in the respective directory can be used for creating partial builds. For example, calling build in \sscli\clr\src\ csharp\csharp merely creates the C# compiler.

Visual Studio ­ in particular its debugging facilities ­ turned out to be a practical tool for getting a detailed understanding of the code. The easiest way to start the debugging environment is by typing:

devenv /debugexe \sscli\build\v1.x86fstchk.rotor\csc.exe [source_file]

The C# compiler basically proceeds in two passes. All metadata is handled during the first pass, while the method bodies are skipped. In the second pass, the previously skipped method implementations are further processed.

The most important data structures of the C# compiler are:

If new functionality is to be added to the compiler, the following modules are the most relevant ones: parser (CParser), class declaration routines (CLSDREC), binding step (FNCBIND), and code generator (ILGEN).

There are basically three different strategies for adding new functionality to the compiler:

Remote Channels
Remembering our final goal of providing an environment for cross-developing programmed devices, we simulate such a device on .NET by an executable module in terms of three static classes (that is classes with static members only) called DistributedObject, ChannelManager, and TransportManager respectively, with tasks summarized by Table 3.

Compared to the local case, the main difference is that clients do not open channels by invoking the desired server objects directly but by sending open requests to the channel manager. In detail, a client sends the specification of both the server object and the channel to the channel manager, which in turn locates the object, advises it to open the specified channel, and returns a reference to the remote channel to the client.

Figure 3 shows both the architecture of the remote channel framework and the traffic flow. In particular, it shows the modeling of remote channel references in the form of local channels provided by the ChannelManager.

Conclusion and Outlook
Although frighteningly huge (in terms of typical ETH software units), the SSCLI turned out to be surprisingly manageable, all in all. The .NET and SSCLI developer lists maintained by the University of Pisa, with their fast response times and helpful answers, were a big plus. Unfortunately, the C# compiler shipped with the SSCLI is not written in its own language but in C++ instead. The voluminous C++ code exacerbated some starting difficulties we had. Given the current implementation of the compiler, Visual Studio came in handy as a great tool both for understanding the technology in detail and for debugging the new code.

Our strategy for adding functionality to the compiler was to express it on the level of the code generator, with the aim of avoiding unnecessary overhead from building up and transforming data structures throughout the compilation process.

Our next steps in this project will be to finish the implementation of the remote channel framework based on the SSCLI and to develop a downloading compiler back end for StrongARM-equipped embedded devices. Our final vision is a system that allows us to program ordinary C# objects upgraded by activities and channels, and then to download their full functionality to embedded devices simply by pressing a symbolic "burn" button.

Acknowledgement
We gratefully acknowledge the opportunity to cooperate with Microsoft in a substantial project, along with the financial contribution provided by Microsoft Research.