A Flick front end is a program that reads an idl source file and from that produces an internal representation of the described interfaces. There is a separate front end for each idl that Flick understands: one for the corba idl, a second for the onc rpc (a.k.a. Sun rpc) idl, and a third for the Mach mig idl.
The corba and onc rpc front ends translate idl files into Flick's aoi representation, whereas the mig front end translates its inputs into Flick's pres_c representation. The difference is due to the nature of the three languages. The corba and onc rpc idls are "pure" interface description languages in that they describe interfaces only in abstract terms. In other words, a corba or onc rpc idl file does not specify how its idl constructs are to be translated into constructs of another programming language (e.g., C or C++). Because corba and onc rpc interface descriptions are free from translation details, a corba or onc rpc idl file can be completely translated -- without loss of information -- into a representation in Flick's aoi format. In contrast, a mig idl specification commonly describes how the interface is to be translated into C functions and data types. For example, the mig idl keywords cusertype and cservertype specify how a mig idl type will be translated into the generated client-side and server-side code! Because mig interface specifications are littered with these kinds of mapping-detail "impurities," mig idl cannot generally be translated into aoi without loss of information. Therefore, Flick's mig front end skips over the aoi format and generates pres_c directly from mig idl.
The nature of any compiler front end is that it is structured around the compiler's input language. Because input languages are often quite different from each other, and because there are many tools for creating compiler front ends (e.g., lex and yacc), Flick does not provide any kind of shared language-processing library for its front ends. (The situation is quite different for later stages of idl compilation. As described in Chapters 11 and 12, Flick's separate "presentation generators" and back ends are quite similar to one another, and therefore, Flick can provide a great deal of library support for all implementations of those compilation steps.)
The library support for Flick's front ends is therefore limited to manipulation of common data types, command line parsing, and a few utility functions:
Because the mig front end produces pres_c, it must link with libflick-pres_c.a, libflick-mint.a, and libflick-cast.a in addition to the libraries listed above.
The next three sections describe each of Flick's front ends.
The corba front end, contained in the fe/newcorba directory, was written especially for Flick. It is a more or less straightforward lex- and yacc-based program that translates corba idl specifications into their aoi equivalents. The front end generally parses corba 2.0 idl, with the addition of the corba 2.1 "long long" data type.
(Prior to August 1996, Flick's corba front end was based on Sun's freely available corba compiler front end. The Sun-based corba front end was contained in the fe/corba directory; hence, the new front end went into fe/newcorba. Although the Sun-based corba front end is still available in the Flick CVS archives, it is not distributed as part of Flick, and it has not been maintained since 1996.)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The mapping from corba idl to aoi is straightforward, since many of the notions in aoi were in fact based on their corba equivalents. Table 10.1 summarizes the translation of top-level corba idl declarations into aoi definitions, and of specific corba idl types into aoi types. idl constant values (e.g., 7, TRUE) are of course translated into equivalent aoi literal constants. Most idl declarations translate into aoi aoi_defs that associate the appropriate names and definitions. idl operations and attributes, for historical reasons, are different, and are translated into special aoi_operation and aoi_attribute structures. Note that certain idl constructs and types, introduced after corba 2.0, are not yet supported. For further details about aoi, refer to Chapter 4.
A few additional comments about the corba front end:
The onc rpc front end, contained in the fe/sun directory, is derived from the 1988 "RPCSRC 4.0" version of Sun's rpcgen program. The principal modification is that original rpcgen back end has been removed and replaced with a custom "back end" that generates aoi. Other minor modifications have updated the 1988 code for ANSI C, fixed bugs, and so on. The onc rpc front end's scanner and parser are hand-coded -- largely unmodified from the original rpcgen code -- and produce a linked list of definition structures. The Flick-specific "back end," contained in fe/sun/xlate.c, simply translates this list of definitions into the equivalent aoi structures.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As with corba idl, the mapping from onc rpc idl to aoi is more or less straightforward, and is summarized in Table 10.2. Because Flick's onc rpc front end is based on a relatively old version of rpcgen, it parses an old version of the idl that predates the current language defined by RFC 1831. In practice, this means:
Flick accepts the various idl "extensions" that are generally accepted by rpcgen, as outlined in Table 10.2. Flick does not, however, support `%' directives in onc rpc idl files. These directives tell rpcgen to pass text directly into the generated output file. Since Flick's onc rpc front end produces aoi, there is nowhere to store literal code, and so Flick simply discards these directives.
Finally, here are a few interesting observations about the onc rpc front end:
const a = b; const b = 1; /* ``Forward'' declaration of `b'. */
const bar = foo; /* `foo' undefined, but `bar' is never used. */
|
rpcgen accepts these kinds of weird declarations simply because it doesn't do anything interesting with them.
The mig front end, contained in the fe/mig directory, is derived from the original mig idl compiler written by Carnegie Mellon University. Many files are copyrighted by CMU:
/* * Mach Operating System * Copyright (c) 1991,1990 Carnegie Mellon University * All Rights Reserved. * * Permission to use, copy, modify and distribute this software and its * documentation is hereby granted, provided that both the copyright * notice and this permission notice appear in all copies of the * software, derivative works or modified versions, and any portions * thereof, and that both notices appear in supporting documentation. * * CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS * CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND FOR * ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE. * * Carnegie Mellon requests users of this software to return to * * Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU * School of Computer Science * Carnegie Mellon University * Pittsburgh PA 15213-3890 * * any improvements or extensions that they make and grant Carnegie the * rights to redistribute these changes. */ |
Flick's mig front end was created by replacing mig's original back end with a new "back end" that produces pres_c files instead of C language stubs. As described previously, Flick's mig front end produces pres_c instead of aoi because the mig idl allows a programmer to specify how idl constructs should be mapped onto the C language. In essence, this means that Flick's mig front end is also a "presentation generator" as described in Chapter 11.
Except for minor maintenance (e.g., updates for ANSI C), the basic scanning and parsing functions are essentially unchanged from the original mig source code. The presentation generator functions of Flick's mig front end are described in Section 11.3.6.
The differences between Flick's corba, onc rpc, and mig front ends illustrate an important strength: namely, that by providing multiple intermediate representations with differing levels of detail, Flick is able to accommodate several very different idls. The differences also highlight a potential improvement to Flick: in particular, the need to extend aoi to accommodate some sort of "annotation" facility that could express mig's "impure" constructs. The aoi format is critical in order for Flick to provide a large, reusable infrastructure for presentation generation, the second stage of idl compilation. The common presentation generator library is designed to read and process aoi descriptions. Since Flick's mig front end does not produce aoi, it cannot directly benefit from Flick's common presentation generation library, and therefore, the mig front end has its own, mostly separate infrastructure for producing pres_c. This duplication of effort could be greatly reduced if it were possible to divide the current mig front end into two programs: a front end producing some sort of annotated aoi, and a separate presentation generator (based on Flick's common library) that read and processed the annotations. An annotatable aoi format would also be useful for other purposes, such as attaching quality-of-service attributes to normally "pure" corba interface descriptions.