IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO.

3, MAY/JUNE 1999 363

Domain-Specific Languages:
From Design to Implementation Application
to Video Device Drivers Generation
Scott A. Thibault, Renaud Marlet, and Charles Consel

AbstractÐDomain-Specific languages (DSL) have many potential advantages in terms of software engineering ranging from
increased productivity to the application of formal methods. Although they have been used in practice for decades, there has been little
study of methodology or implementation tools for the DSL approach. In this paper, we present our DSL approach and its application to
a realistic domain: the generation of video display device drivers. The presentation focuses on the validation of our proposed
framework for domain-specific languages, from design to implementation. The framework leads to a flexible design and structure, and
provides automatic generation of efficient implementations of DSL programs. Additionally, we describe an example of a complete DSL
for video display adaptors and the benefits of the DSL approach for this application. This demonstrates some of the generally claimed
benefits of using DSLs: increased productivity, higher-level abstraction, and easier verification. This DSL has been fully implemented
with our approach and is available. Compose project URL: http://www.irisa.fr/compose/gal.

Index TermsÐGAL, video cards, device drivers, domain-specific language, partial evaluation.

1 INTRODUCTION

I N contrastto a general purpose language (GPL), a domain-

specific language (DSL) is a language that is expressive
uniquely over the specific features of programs in a given
A DSL may also be seen as a way to parameterize a
generic application or to designate a member of a program
family. A program family is a set of programs that share
problem domain. It is often small and more declarative than enough characteristics that it is worthwhile to study them as
imperative; it may be textual or graphic. DSLs have also a whole. In fact, designing a DSL actually involves the same
been called application domain languages [7], little or micro- commonality analysis [15] that is used in the study of a
languages [2], and are related to scripting languages. DSLs program family, i.e., determining assumptions that are true
have been used in various domains such as graphics [14], for all members of the family and variations among
[19], financial products [1], telephone switching systems members. This process should be performed by both
[15], [21], protocols [8], [31], operating systems [28], and domain experts and software engineers.
robot languages [5]. Languages such as SQL, TEX, and Unix Though actual uses of DSLs record benefits such as
shell languages may also be considered DSLs. productivity, reliability, and flexibility [20], implementing
Software architectures based on DSLs are primarily DSLs is often difficult and costly [9]. There are two kinds of
aimed at achieving faster development of safer applications. approaches to language implementation, each with sig-
Because constructs in a DSL abstract key concepts of the nificant disadvantages. Approaches that are based on
domain, the developer (that does not have to be a skilled compilers, such as application generators (translation from
programmer) can write more concise and higher level the DSL to a GPL), are not easy to write or to extend, and
programs in less time. Programming with a DSL also extensions require skills in compiler technology that cannot
contributes to safety because it is less error-prone than with
be expected from ªdomain developers.º On the other hand,
a GPL. Additionally, high-level constructs translate, in
practice, into the reuse of validated components. Moreover, approaches that are based on interpreters are easier to write
when the language is small and specific, it is possible or or to extend, but are less efficient [4]. This implementation
easier to apply automated proof techniques that have been issue also impacts maintainability because complexity in a
developed for general purpose languages, but have had DSL compiler defeats the software engineering goals of
limited success due to the generality of GPLs. For example, using a DSL [33]. Depending on one's objectives, either style
termination properties may be considered if the language is of implementation is thus chosen: application generator or
not Turing-complete. Similarly, it is easier to build test interpreter.
generation tools. We have proposed a framework for the development of
application generators that reconciles both alternatives,
. S.A. Thibault, R. Marlet, and C. Consel are with IRISA/INRIA, Universite offering the flexibility of interpreters and the performance
de Rennes 1, Campus Universitaire de Beaulieu, 35042 Rennes cedex, of compilers [30]. The framework relies on partial evaluation
France. E-mail: [email protected]; {marlet, consel}@irisa.fr. [16], [18], a program transformation technique that is well
http://www.irisa.fr/compose
suited to automatically transform interpreters into compi-
Manuscript received 19 June 1998; revised 9 Feb. 1999. lers [17]. Partial evaluation exploits known information
Recommended for acceptance by D.S. Wile.
For information on obtaining reprints of this article, please send e-mail to: about a program's input to be able to evaluate parts of a
[email protected], and reference IEEECS Log Number 109170. program in advance. Given a program and the known
0098-5589/99/$10.00 ß 1999 IEEE
364 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 3, MAY/JUNE 1999

portion of its input, a partial evaluator produces a family and can be represented using a microlanguage, i.e., a
specialized program. In this new, semantically equivalent DSL. In other words, the generic program interprets DSL
program, computations depending on known values have programs to know what actions pertaining to the applica-
already been performed. Given an interpreter for a DSL tion family to perform. The possible actions define an
(that takes as arguments a DSL program and the input data abstract machine that is adapted to the domain and the
of the DSL program) and a DSL program, partial evaluation application family, whereas an interpretation layer, map-
automatically yields a specialized interpreter, i.e, a com- ping constructs to actions, provides an interface between
piled version of the DSL program. DSL programs and the abstract machine. The performance
Our framework is structured into two parts that come overhead due to genericity, in the interpretation layer as
after the family analysis. The first part consists of the well as in the adaptation of the abstract machine, calls for
definition of an abstract machine, whose operations can be optimization via partial evaluation.
viewed as generic components that capture important This approach is the basis of a general framework for
operations of the domain. The second part is the definition designing and implementing DSLs. This framework is
of a DSL in terms of the abstract machine operations, thus sketched in Fig. 1; it is described further in the following
providing a high level interface to the abstract machine. The subsections. More details concerning the impact on reuse
use of partial evaluation in our framework is twofold, (for code as well as expertise) and advantages over other
corresponding to each part: it maps a DSL program into an application generators designs are given in [30].
abstract machine program, removing the interpretation
layer, and an abstract machine program into an efficient 2.1 Analysis
implementation. The development of this framework is The first phase of the framework is a family analysis phase.
supported by industry partners for realistic applications. This phase studies features that are present in all members
This paper describes a realistic application of our of the family and variations among members. It can be
framework for the automatic generation of video card conducted using a methodology such as FAST's common-
drivers. This domain naturally forms a program family, for ality analysis [15]. The family analysis may also rely on a
which DSLs are well suited. We present the design and domain analysis [23], [25], [27], which discovers the com-
definition of a complete DSL for video display adaptors. monalities in a domain. This analysis phase has two sets of
Concerning performance, we show how partial evaluation outputs, which lead to the design of both a DSL and an
can yield efficient drivers. Concerning safety, we insure that abstract machine.
all generated drivers can be proven to terminate and define
2.2 Abstract Machine Design
some analyses that can greatly improve their reliability. The
DSL has been fully implemented with our approach and is The analysis phase identifies key objects of the domain and
available at URL http://www.irisa.fr/compose/gal. program family, as well as basic operations on those objects.
Our contributions can be summarized as follows: These operations are used to define an abstract machine,
which offers a model of computation that underlies all
.We validate our framework of application generator programs in the family [9]. Other operations are also
design on a realistic example: video card device included so that it is possible to construct any program in
drivers. the family from those operations.
. We define a DSL for generating such drivers. This The use of abstract machines is a natural progression
restricted language allows program verifications. from established reuse practices. Starting from the idea of
. We provide a flexible implementation of this highly parameterized subroutines in a reuse library [6], one
language that generates efficient video drivers. might consider these to be generic components or opera-
. We illustrate the benefits of DSLs as a software tions that provide a level of abstraction. This level of
architecture. abstraction provides insulation between the definition of
The rest of the paper is organized as follows. Section 2 the operation and an implementation. Given the context of a
describes our framework for application generator design in domain-specific solution, it then seems reasonable that for a
further detail. Section 3 presents the domain of video card given domain, we can define a collection of related
drivers. Section 4 describes the two-level design: abstract operations that cooperate to solve the relevant problems
machine and graphics adaptor language. Section 5 discusses in the domain. Finally, by enforcing an explicit state, as
the results of applying this approach to the domain of video opposed to threading arguments across abstract machine
drivers. Section 6 summarizes the results of this experiment instructions, we obtain an abstract machine model that can
and identifies future work, both for the language and the be implemented efficiently.
framework. There are many advantages to this approach. One of
these advantages is the opportunity to have several
implementations of a single abstract machine. The same
2 A FRAMEWORK FOR DESIGNING AND abstract machine could also be implemented in different
IMPLEMENTING DSLS languages. Another benefit of the approach is that it
In a previous paper, we presented an approach to provides a formal model of computation that can be
application generator design [30]. In this approach, we reasoned about using well-established techniques for
consider the implementation of a program family as a single abstract machines [26]. Being able to reason about opera-
generic program. The parameterization of this generic tions in this way enables the verification of certain proper-
program corresponds to variations within the program ties about DSL programs, or derive other properties like
THIBAULT ET AL.: DOMAIN-SPECIFIC LANGUAGES: FROM DESIGN TO IMPLEMENTATION APPLICATION TO VIDEO DEVICE DRIVERS... 365

Fig. 1. DSL design and implementation framework.

time complexities. The abstract machine model also straightforward approach to implementing a DSL is to
provides the right level of decomposition to increase reuse build an interpreter. While an interpreter directly interprets
of the abstract machine [35]. each language construct to produce the results, a compiler
produces a program, which when executed produces the
2.3 Language Design results. Thus, the compiler approach introduces an indirec-
The analysis phase has three other outputs: 1) terminology, tion which makes it more difficult to construct. Moreover,
2) commonalities, and 3) variations among the family an interpreter facilitates prototyping. For these reasons, we
members. This information, with the addition of constraints propose an approach based on interpreters.
such as the level of the language or its analyzability, is used In our framework, the implementation of the DSL is thus
to design the DSL. expressed as an interpreter, which calls the abstract
The idea is that the DSL is implemented in terms of the machine operations. The abstract machine is typically
abstract machine. The key difference between the DSL and implementated as a highly parameterized library.
the abstract machine is that a DSL program describes what Just as there could be many implementations for an
an application does and an abstract machine program abstract machine, this staged framework also provides the
describes how the application operates. The link between the possibility to have many DSL languages for one abstract
DSL and the abstract machine is that the DSL can be viewed machine. Since the abstract machine can express a wide
as a glue language for composing abstract machine range of applications within the domain, and the DSL only
operations, i.e., an interface to the abstract machine. This a restricted subset of these, it is useful to have multiple
interface first provides a superior abstraction to the DSL DSLs for different users. For example, a DSL could manage
program designer, and second, further restricts the applica- a whole database while a subset of this DSL might only be
tions that can be expressed, thus forming the program able to express queries.
family. The DSL is generally designed to express programs Although interpreters are easier to construct they are
in terms of domain-specific concepts. For usability and also less efficient. Similarly, the genericity of a parameter-
analyzability, it should have a semantics as restricted as ized library introduces execution-time overhead. In the next
possible, depending on the future requirements of the subsection, we present an approach to obtaining efficient
program family. implementations based on partial evaluation.

2.4 Structuring the Implementation 2.5 Efficiency via Partial Evaluation

A DSL can be implemented as either an interpreter or a There are two identified sources of inefficiency in the
compiler (to a target machine or a GPL). The most framework presented so far: the DSL interpretation layer
366 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 3, MAY/JUNE 1999

and the parameterization of the library implementing the

abstract machine. In particular, interpretation has been cited
to be one to two orders of magnitude slower than compiled
code [29]. There exist a technique to automatically remove
these two kinds of overhead: partial evaluation. As a matter
of fact, partial evaluation has proved to be very effective in
mapping software architectures to efficient implementa-
tions [22].
Partial evaluation. Partial evaluation is a fully auto-
matic program transformation which specializes a pro-
gram to a particular context reducing its execution time
and, in some cases, its size [10], [18]. A specialization
context is defined by assigning values to some subset of
a program's inputs. More specifically, consider a program
p, taking some argument data d and producing a result r,
which may be written as p d† ˆ r. If d can be split into
d ˆ d1 ; d2 † where d1 is a known (i.e., it does not vary)
subset of the input, which describes the context, and d2 is
yet unknown, we may form a new program p; d1 † that
waits until d2 is available and then calls the original p
program on d1 ; d2 † to produce the same result r. In
other words, p; d1 † d2 † ˆ p d1 ; d2 † ˆ r. However, since
d1 is known, computations relying on d1 can be
performed before d2 is actually available. Therefore, we
can form a new program pd1 , equivalent to p; d1 †, where
computations depending on d1 have been eliminated. We
thus have pd1 d2 † ˆ p d1 ; d2 † ˆ r. The program pd1 is
Fig. 2. Specialization with respect to fmt = ªn: %dº.
called a specialization of p with respect to the known
input d1 . The known inputs representing the context are
resulting functionality is equivalent to that of a compiler at
also called static whereas the other unknown inputs are
called dynamic. A partial evaluator is a program PE the cost of writing an interpreter. The use of partial
which computes pd1 : P E p; d1 † ˆ pd1 . evaluation, that makes up a standalone application, given
For the case study described in this article, we have used the generic program and a DSL program, can be considered
a partial evaluator named Tempo Specializer [10], [11]. an application generator.
Tempo is a fully automatic partial evaluator for C Ensuring efficiency. If the mapping performed by the
programs. Tempo can specialize programs at compile time interpretation layer depends only on the input program and
(i.e., source-to-source transformation) as well as at run time. the input program is a known input, a partial evaluator
Users of Tempo specify inputs to the program entry point should be able to eliminate the entire interpretation layer.
and global variables as either static (i.e., already known) or Thus, as shown in Fig. 1, when the interpretation layer is
dynamic (i.e., yet unknown). specialized with respect to the input program, only
An example of partial evaluation. Fig. 2 shows an invocations of the abstract machine instructions should
example of specializing a simple version of printf. The top remain: the result is an abstract machine program. In order
part of the figure is the original code while the bottom part to ensure that the interpreter has been correctly structured
is the result of specializing the function with the input fmt to eliminate the interpretation layer, we rely on a program
equal to ªn: %dº. In fact, this example represents a very analysis performed during partial evaluation: binding time
simple interpreter in the two-level framework in Fig. 1. The analysis.
fmt parameter is a program which specifies how the data in The actual partial evaluation process is split into two
the val parameter should be displayed. The putint, phases: a binding-time analysis and the actual specialization
putchar, and abort functions are the abstract machine transformation. During the binding-time analysis, depen-
instructions that are used to print simple values. The dencies are propagated to determine for each subexpression
mini_printf function represents the interpretation layer of a program if it depends only on known values and can,
which decides when and how to invoke the abstract thus, be evaluated. As a result, each subexpression is given
machine instructions to implement the behavior specified a binding time of static to mean it depends only on known
in the fmt argument. inputs or dynamic otherwise. The second phase performs
Partial evaluation of interpreters. Given an interpreter the specialization by evaluating the static expressions and
for a DSL (that takes as arguments a DSL program and the outputting the specialized program.
input data of the DSL program) and a known DSL program, The code in the top of Fig. 2 depicts a bind-time
partial evaluation can be applied to automatically produce annotated function. The underlined expressions have
an implementation that is specialized with respect to the dynamic binding times and the rest have static binding
DSL program, i.e., a compiled DSL program. Thus, the times. As expected, the only dynamic expressions in
THIBAULT ET AL.: DOMAIN-SPECIFIC LANGUAGES: FROM DESIGN TO IMPLEMENTATION APPLICATION TO VIDEO DEVICE DRIVERS... 367

mini_printf are calls to the abstract machine instruc- provide similar sets of functionalities (e.g., changing the
tions. Thus, all the interpretation is evaluated at specializa- display resolution).
tion time and all that remains are these calls, as shown in Although all adaptors provide similar functionalities,
the bottom of Fig. 2. their programming interface is different from vendor to
The following rules define the requirements on the vendor, and often between successive models of the same
structure which guarantee the elimination of the interpreta- adaptor. This is true of most devices, and is resolved by the
tion layer. use of device drivers. Device drivers generally consist of a
library of functions that implement a standard API that is
1. References to the abstract machine state in the fixed for all devices. Thus, the driver's purpose is to
interpretation layer may only appear as subprogram translate the standard API operations into the operations
arguments. required by a specific device, providing a uniform interface
2. The abstract machine implementation may not to the operating system and applications.
contain any references to the interpreter state. Video device drivers provide two main services to the
In our application of Tempo, we ensure the successful operating system and applications. The first is to put the
application of partial evaluation via the separation of the graphics display into different video modes. A video mode
abstract machine and the interpreter, each having its on (or graphics mode) is defined by the horizontal and vertical
state represented in C by global variables. The interpreter resolution, the number of colors per pixel and screen refresh
state is specified as static and the abstract machine state is rates. The second service provided by the driver is to
specified as dynamic. The visualization of the binding times provide access to hardware drawing operations. For
produced by Tempo analyses lets the user assess the correct example, most video cards provide line drawing hardware,
separation between the interpreter and the abstract ma- which draws lines on the display at a much faster rate than
chine, and thus the successful partial evaluation. would be possible in software.
In Fig. 1, a second step of partial evaluation is shown in
which the implementation of the abstract machine is
specialized with respect to the abstract machine program. 4 APPLICATION OF THE APPROACH
The reason for this second step is that the abstract machine We have applied the approach described in Section 2 to a
operations are often highly parameterized reusable compo- family of device drivers for video adaptors. We considered
nents. It may also be desirable to eliminate the genericity an already existing set of device drivers from the XFree86 X
introduced by this parameterization. If these parameters Window server created by The XFree86 Project, Inc. [36].
depend only on the input program, then the abstract The XFree86 SVGA server is a generic X Window server,
machine program will contain instructions with constant written in C, supporting several different cards using a
values for these arguments. The second step of partial device driver architecture. This server contains drivers for
evaluation will exploit these values to remove the genericity cards from about 25 different vendors. Additionally, each
from the instructions' implementations. Specialization can driver supports as many as 24 different models from the
also optimize inefficiencies introduced by the boundaries same company. This structure alone indicates that there is
between operations. The reason that partial evaluation is enough similarities between models of the same vendor to
done twice is to obtain the abstract machine program for implement them as a generic program, but that it is not
analysis or any other reason. If the abstract machine reasonable to do so for multiple vendors. This may be due
program is not needed, a single application of partial to efficiency, but more likely is due to the lack of a
evaluation to the whole interpreter will yield the same methodology to handle larger scales of variation.
results. The remainder of this section details the application of
There is an important difference between the genericity our approach to the construction of an application generator
removed from the interpretation layer and that of the of video drivers (for different vendors) for the X Window
abstract machine layer. If the interpreter structure of our server. We first discuss the definition of an abstract machine
framework is respected then the interpretation layer is for the domain, identified by studying the existing device
guaranteed to be removed. However, there is no guarantee drivers. Then we describe a DSL for generating video
on how much of the abstract machine layer will be drivers and related design issues.
removed.
4.1 The Abstract Machine
The abstract machine for the video driver domain was
3 VIDEO DRIVER DOMAIN
designed primarily by studying the implementation of
This section introduces the domain of the experiment: video existing drivers. The abstract machine was also iteratively
adaptor device drivers. A video adaptor(or video card) is a refined during the development of a DSL. We identified
hardware component of a computer system which stores three patterns which appeared in the existing drivers that
and produces images on the display. Video cards consist of could be used to guide the definition of abstract machine
a frame buffer, and a graphics controller. The frame buffer is operations.
a bank of high speed memory used to store the display data, Operation pattern. The first of these patterns corre-
including the currently visible image. The graphics controller sponds to simple atomic operations in the abstract machine.
consists of two main functionalities: producing the video There are two forms in which this pattern appears: as
signal for the display, and providing access to the frame repeated fragments of code that differ only by data, and as
buffer to create the display image. Graphics controllers all fragments which perform the same treatment but have a
368 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 3, MAY/JUNE 1999

small number of variations on how it is performed. In the Bool ClockSelect (int no)
first case, the fragments are often already identified and {
switch (no) {
placed in a library or defined as a macro. These fragments /* Save the clock value. */
directly correspond to abstract machine operations. case CLK_REG_SAVE:
As an example of the second case, the device drivers are Series of I/Os and logic operations.
dominated by occurrences of code fragments which read or break;
write data from or to the video card. Communication with /* Restore saved clock value. */
hardware devices can be handled in a small number of case CLK_REG_RESTORE:
A second series of I/Os and logic operations.
different ways, and the scheme chosen varies from vendor break;
to vendor. There were several occurrences of three of these /* Set the clock value to no. */
different schemes of I/O, differing only in certain data (e.g., default:
the I/O address). These fragments were captured in a single A third series of I/Os and logic operations.
abstract machine operation defined as follows: }
}
write_port(port_number: integer,
index: integer, The series of I/Os and logic operations in this example
indexed: boolean, follow the combination of operations pattern, and can be
pair: boolean, constructed by sequences of abstract machine operations.
pci: boolean) For this pattern, we introduce higher-order abstract
This instruction is parameterized by flags to specify which machine operations. That is, abstract machine operations
scheme to use (indexed, paired, or PCI), and the data used which take sequences of abstract machine operations as
by the scheme to perform the I/O (port_number, index). parameters. These parameters correspond to the contained
Combination of operations pattern. The second type of fragments that follow the combination of operations
pattern recognized can be identified as expressions or pattern. The example above is captured by the following
combinations of operations. This pattern is characterized by abstract machine operation:
expressions or combinations of operations that have no
change_clock(save_clk: instructions,
commonalities between members of the family. For exam- restore_clk: instructions,
ple, in the device drivers there are sequences of shifts and set_clk: instructions)
logical expressions which are different for every driver.
Although there are no commonalities in those expressions Conclusion. Using these patterns with existing exam-
from one driver to the next, we can identify a sufficient set ples, we were able to define an abstract machine that could
of operations to construct any instance. The selection of express the behavior of any particular device driver.
these operations depends not only on the existing samples, Although they were typically easy to recognize, it is
but on an understanding of the domain, and speculation on important to realize that it was necessary to abstract from
the future of the domain. certain details in order to see the different patterns; e.g., in
The following code fragment shows an example of this our experiment, the examples were mostly written by
pattern from one of the existing drivers. different people, who had different styles of programming,
and sometimes took different approaches to the same
outb(0x3C2, ( inb(0x3CC) & 0xF3)
((no << 2) & 0x0C)); problem. In this situation, it was necessary to determine if
outb(OTI_INDEX, OTI_MISC); the same functionality could be implemented with a
outw(OTI_INDEX, OTI_MISC | common structure, which happened to always be the case.
((( inb(OTI_R_W) & 0xDF ) |
(( no & 4) << 3)) < < 8)); 4.2 The GAL Language
In this section, we present the Graphics Adaptor Language
This portion of the driver maps the value of no onto the
(GAL) for video device driver specification. In order to
appropriate registers in order to select the clock. For a given
driver, there may be any number of reads, writes, shifts and understand where the language comes from, it is important
logic operations, but no other operations. Thus, we can to know what the essential variations are among video
implement any given driver with a sequential composition adaptors. The remainder of the section describes the
of a small number of abstract machine operations. variations that exist between cards and the corresponding
Control pattern. The last pattern consists of code constructs in GAL that capture them. A complete example
fragments that share a common control structure, but of a GAL specification is described in Appendix A.
contain code fragments matching the combination of
4.2.1 Ports, Registers, Fields, and Params
operations pattern previously discussed. For example,
consider a function of the device driver which is used to A video adaptor is controlled by setting certain parameters
save, restore, and set the clock value on the video card.1 stored in hardware registers of the card. These registers
This function has the following form: have addresses. A single parameter may be stored in
multiple registers and only certain bits of the registers may
be used. Thus the layout of the parameters on the register
space is the first major variation between cards.
Access to the registers are provided through various
1. Video cards have programmable clocks which can be set to different communication schemes. As mentioned in the previous
frequencies to control the video refresh rate. section, there is a small number of different schemes that
THIBAULT ET AL.: DOMAIN-SPECIFIC LANGUAGES: FROM DESIGN TO IMPLEMENTATION APPLICATION TO VIDEO DEVICE DRIVERS... 369

can be used to communicate with a hardware device TABLE 1

from a program. The choice of communication scheme is Predefined Felds and Params
the second major variation between cards. We define
several concepts to describe these notions of communica-
tion and register layout.
Ports. The first concept is the port which is used to define
a point of communication. For example, the declaration
port svga indexed := 0x3d4;

defines a port named svga, which uses an indexed

communication scheme at the I/O address 0x3d4. This is
a standard port used by many video cards.
Registers. A second concept is provided by the register
declaration, which defines how to access registers on the
card using the defined ports. For example, the declaration

register ChipID := svga(0x30);

defines a register ChipID, which is accessed through port
svga, at index 0x30.
Fields. The next concept is specified with a field
declaration. The field declaration defines where a logical
value is stored (in which bits of what registers) and a
mapping from logical values to actual stored values. For
example, the declaration NoClocks constant defines the number of clocks available,
and the ClockSelect field defines the field which selects
field LogicalWidth := the clock.
Control2[5..4] # Offset scaled 8;
For cards that have programmable clocks, a special
defines a field LogicalWidth, which is stored in bits 5 and construct is defined to specify how to program the clock.
4 of the Control2 register and the entire Offset register. For example,
Additionally, the mapping clause (scaled 8) specifies that
the value stored in the register is 1/8th the actual value. The clock f3 is 14318 * f3M / (f3N1 * f3N2);
mapping is needed because cards often store a value which defines a clock named f3, which is programmable accord-
is some function of the field's actual value.
ing to the equation on the right. The equation defines the
Parameters. Related to the field declaration, the parameter
declaration is the definition of a constant value that is either frequency generated based on programmable values, which
explicit in the specification or read from the card during are defined elsewhere by the three fields f3M, f3N1, and
configuration. An example of the former case would be f3N2. Given the desired clock frequency, the device driver
uses the specified equation to find values of f3M, f3N1, and
param NoClocks := 4; f3N2 which approximate this frequency as closely as
possible.
The majority of a GAL specification consists of the
definition of fields for standard values that are used to
4.2.3 Identification
control the video adaptors and parameters which deeter-
mine certain features of the card (e.g., size of the frame The fourth major variation observed among video cards is
buffer). Table 1 lists some of these predefined field and how the card is identified. This information is required for
parameter names that can be defined in GAL specifications. systems which dynamically configure themselves to use
whatever card is available at that time. Card identification
4.2.2 Clocks uses a small number of predicates which test the card and
A third major variation between different adaptors is the follows a decision tree to decide if the card is supported by
use of clocks. All adaptors have a clock which controls the driver and which one.2 Thus, we define an appropriate
the frequency at which data is sent to the display. This construct for specifying this type of decision tree in GAL.
frequency needs to be changed for different resolutions, The following is an example of this identification
and there are two approaches to doing this. One is to construct.
have a fixed number of frequencies to choose from, and
the other is to have a programmable chip that can identification begin
generate many frequencies by changing its parameters. 1: writable(Segment) => (true => step 2);
The cards with a fixed number of clocks vary in the 2: Chip_id => (1 => oti087,others => step 3);
number of clocks and the frequencies provided, while the 3: Chip_id2 => (0 => oti037c, 2 => oti067,
cards with a programmable clock vary in how the clock is 5 => oti077);
end identification;
programmed and its range of frequencies.
A card that has fixed clocks can be specified by defining 2. One device driver often supports multiple cards from the same
a parameter NoClocks and a field ClockSelect. The vendor.
370 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 3, MAY/JUNE 1999

This example identifies one of four models (oti037c, oti067, This example specifies that if the card identified at run-time
oti077, oti087) of cards that use an OTI graphics controller. is a S3_TRIO32 or S3_TRIO64, then the card has four fixed
The construct defines a series of steps numbered 1±3 to the clocks selected by bits 3 and 2 of the Miscr field. All other
left. At each step, the expression to the left of the arrow is cards have 16 clocks selected by bits 3 down to 0 of the
evaluated and the result is compared to the list of decisions Control field.
on the right. If no decision is matched on the right, then
identification fails and indicates that the driver does not 4.3 Design of GAL
support the card. Possible decisions are to identify the card This section discusses some of the many forces that
or proceed to another step. Step 2, for example, reads the influenced the design of GAL. The first two subsections
value of the Chip_id register, and if the result is 1, describe two main inputs to the design process: A definition
identifies that an oti087 is present, otherwise proceeds to of variations in the family and knowledge about the
step 3 for further tests. The stepwise syntax reflects the way domain. In our case, the domain knowledge came from
diagnostic procedures are commonly described in manuals. existing documentation used by domain engineers. Other
important issues are the level of abstraction, the level of
4.2.4 Modes restriction, readability, maintainability, etc. While the level
The final major variation between cards is that many of abstraction and the level of restriction are of particular
adaptors require some flags be set under certain operating importance for DSLs, issues like readability and maintain-
conditions. These are referred to as modes of operation in ability apply to both DSLs and GPLs.
GAL, and are defined with the mode construct. The mode
construct is used to specify a predicate and a sequence of 4.3.1 Defining Variations
assignments to fields, which enable or disable the corre- One of the main inputs to the design of a DSL is a
sponding mode of operation for the video card. For description of the variations that exist among the target set
example, of applications. The defined variations imply requirements
on the DSL in order to distinguish among instances of the
mode HighRes := HTotal > 800; program family. In our case, these variations came from a
enable HighRes sequence is study of the documentation of existing video cards. In
Control[5] <= 1; addition to studying different cards, inspection of the
existing device drivers provided a more detailed source of
This mode declaration defines a mode, HighRes, which
variations at the implementation level. For example, given
indicates that a '1' must be stored in bit 5 of Control in
that there were a small number of ways to communicate,
order to use a video mode in which the horizontal
which varied among cards, there must be some construct in
resolution is greater than 800 pixels. In our implementation, GAL specifications, which would allow the selection of the
the predicate HTotal > 800 is tested after changing the correct communication scheme. Some of this information
video mode; if it is true, the sequence Control[5] <= 1 is can also be extracted from the parameters of the abstract
executed. machine operations.
In addition to user defined modes, there are also a few
built-in modes. The built-in modes have fixed predicates, 4.3.2 Domain Knowledge
but allow the specification of enabling and disabling The other main input to the DSL design process is
sequences. For example, the built-in mode SVGAMode is knowledge of the domain in terms of the abstract objects
true for all graphics modes and thus the user-defined or concepts and terminology used in the domain. This
enabling sequence is executed each time the mode is knowledge may come from a domain expert or from
changed. existing natural language specifications, as in our experi-
ment. This is an important input because it leads to a more
4.2.5 Run-Time Variations abstract user-level DSL. An appropriate terminology pro-
In addition to the variations that exist between cards, there vides a DSL that is familiar to people of the domain. The
are variations within a single driver that depend on identified abstract objects that are affected by variations in
conditions not known until run-time (of the driver). For the program family provide starting points for declarative
example, some video adaptors operate differently depend- constructs.
ing on the hardware bus utilized (AT, PCI, or VLB). In this experiment, we looked at several English
Additionally, if one wants to build a single device driver for specifications of video cards to identify the concepts and
a number of models from the same vendor, the variation terminology used within the domain. The clocks, ports, and
between those models has to be chosen at run-time. In GAL, registers are examples of concepts in the domain that we
the cases construct is used to describe this type of identified. After identifying them, we considered what
variation. attributes of the objects were related to variations within the
As an example, the following statement is used to define program family. Declarative statements were then defined
the clocks for different models of S3 cards. to specify the values for the attributes that varied. Thus, the
abstract objects identified in our experiment directly
cases translated to declarative constructs in the DSL. Addition-
for S3_TRIO32, S3_TRIO64 ally, the relationship between the objects translated into a
field ClockSelect := Miscr[3..2];
for others reference relationship in the DSL. For example, registers are
field ClockSelect := Control[3..0]; defined by references to port definitions. This may suggest
end; the use of an object-oriented analysis for DSL design.
THIBAULT ET AL.: DOMAIN-SPECIFIC LANGUAGES: FROM DESIGN TO IMPLEMENTATION APPLICATION TO VIDEO DEVICE DRIVERS... 371

4.3.3 Level of Abstraction On the other hand, the cases construct introduced in
One of the most important goals guiding the DSL is to GAL is an interesting example of a construct which possibly
provide a high-level of abstraction. In particular, we wish to has applications in DSLs in general (when a predefined
intentionally focus on raising the level of abstraction from abstraction may, conditionally, have one of several defini-
the abstract machine level. In fact, it may be desirable to tions), but is not useful for GPLs, since the behavior is
include information in the DSL, which is not even used for totally described by the program itself and abstractions are
implementation, but may be used in analyses or for explicitly invoked. One of the main purposes of introducing
documentation. a DSL and an application generator is to embed knowledge
As an example of abstraction, the abstract machine about how to implement certain operations of the domain
developed for the video device drivers includes operations into the application generator. As a result, there are often
for doing bitwise shifts and logical operations. However, declarative constructs in DSLs that are translated into
these types of expressions do not appear in GAL because executable code by the application generator, which is not
we intentionally introduced the idea of fields and para- generally true of general purpose languages. Since these
meters to eliminate the low-level procedural nature of these declarations really imply operations, there is often a need to
make choices between the implied operations that can only
expressions. This also eliminates a common source of
be made at run-time. This leads to the type of dynamic
errors.
selection of multiple definitions that is provided by the
After a preliminary design of the language, the language
cases statement. Since a main motivation of utilizing a
and abstract machine are revised in an iterative way. The
DSL is to raise the level of abstraction, it will be common for
revision process must satisfy the correspondence constraint
DSLs to have declarative objects which imply operations
between the language and abstract machine: it must be
and require this dynamic selection. Thus, we suspect that
feasible to provide a mapping from the language to the
this construct will be useful in DSLs in general, and in fact
operations of the abstract machine as an interpreter. During
have found it necessary in other DSLs that we have
this revision process the level of abstraction must also be
experimented with. This suggests that there are new
considered. Although it is possible to move all of the
constructs and principles that are interesting and unique
functionality of the language into the abstract machine,
to DSLs and warrant study.
making the mapping essentially one-to-one, there must be
conscious decisions made about where to draw the line
between the interpreter and the abstract machine. The 5 RESULTS
primary consideration here is the separation of functionality In this section, we present the results of applying our
from specification. The abstract machine should specify framework to the domain of video device drivers. The
how applications in the family are implemented. The results are presented in terms of the advantages we have
interpreter, on the other hand, should specify how to make gained from using our approach for this family of drivers.
the design decisions required to map a design specification There are two aspects of the approach that led to these
(i.e., DSL program) into an implementation (i.e., abstract advantages. One aspect is the use of DSLs and application
machine operators). generators in general, and the second is specific to our
framework for application generator design.
4.3.4 Level of Restriction
Another major concern is restricting the language. It is 5.1 Domain Specific Language
important to consider what types of analyses might be The GAL language demonstrates many advantages of using
performed on specifications in the DSL in order to ensure an application generator with a DSL for the video device
that the language is restricted enough to make the analyses driver domain. These benefits include an increased level of
feasible. For example, in the GAL language we have abstraction, the possibility of automated program analyses,
intentionally not introduced loops, which ensures that all reuse, and productivity.
device drivers can be proven to terminate. Additionally, we There are two significant examples of the benefit of a
perform other analyses to detect common errors in the higher level of abstraction. The first, already discussed in
specification by providing explicit information that is Section 4.3.3, is the use of ports, registers, and fields to
difficult or impossible to extract from general purpose abstract from the low-level bitwise operations that would
languages. An example of this is checking that the bits of otherwise have to be used. This eliminates many common
each register belong at most to one field. This information errors, is more readable, and easier to write. A second
could not be retrieved, in general, from a driver imple- example is an abstraction from implementation. The X
mented in a language such as C. Window server can be considered a framework, where the
device driver provides the additional functions. As with
4.3.5 GPL Principles any framework, the device driver needs to be implemented
In addition to the design goals that are specific to DSLs, in a certain way in order to be compatible with the server
there are several principles of general purpose language and requires considerable knowledge about the framework.
design that also apply to DSL design. General purpose Using an application generator, knowledge about the
languages can also help DSL design by providing a framework and compatibility issues are coded in the
standard set of constructs that may be restricted for use in application generator, and hidden from the designer.
the DSL, but would still be recognized as a common GAL also demonstrates that automatic analyses can be
construct. performed on the DSL, which would not be possible or
372 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 3, MAY/JUNE 1999

feasible with a general purpose language. Example analyses as implementing a single driver directly, as the code is very
that are performed on GAL specifications include detecting similar. Since we had existing device driver implementa-
unused definitions, checking for exhaustive identification of tions, some of the abstract machine code could be reused
video cards, identifying overlap in field definitions, check- from those drivers.
ing for minimum requirements on predefined fields, and Table 2 summarizes the number of lines of code in the
generating a card profile (summary of card characteristics). GAL system in comparison to writing drivers in C. The
None of these analyses would have been feasible on the interpreter for GAL consists of 4,300 lines of C code and an
existing device drivers implemented in C. Using GAL not automatically generated parser, much of which concerns
only makes the analyses feasible, but also easy to imple- building an environment and look-up routines for declara-
ment. For example, all of these analyses for GAL were tions. Thus, together the system consists of about 5,500 lines
implemented within a single day. of C code. We can compare this to the size of the existing
One particularly interesting analysis is the one which hand-coded drivers which averaged about 1,500 lines.
generates a card profile. Generating a card profile is an Though the effort required to build an interpreter should
analysis which, from the GAL specification, produces a be less than that for building a device driver, we can
summary of the video modes that are supported by the estimate that the application generator requires a little more
generated device driver. Fig. 3 shows an extract of the than 3.5 times the effort of an individual driver (assuming
profile generated for the S3 specification listed in Appendix code size proportional to effort).
B. A profile is generated for each subset of cards in the For the version of the X Window server we used, the
specification that have the same profile. The figure shows existing drivers together consisted of 35,000 lines of code.
the profile for the S3_TRIO64 and S3_TRIO32. This
The GAL specifications that have been written are at least a
summary can be compared with vendor specifications to
factor of 9 smaller than the corresponding existing C driver .
find mistakes in field definitions and provides automatic
We can then estimate that these drivers could be generated
documentation of the specification.
from less than 4,000 lines of GAL specifications plus the
Finally, using an application generator provides reuse by
5,500 lines of the generator, totaling less than 10,000 lines.
capturing design knowledge. In the domain of video device
This is an estimated productivity gain of a factor of 3.5. In
drivers there are large benefits of reuse because there is a
practice there would be a higher gain, since GAL specifica-
large growing number of video cards which could poten-
tions are easier to write then the corresponding C driver. In
tially be generated from a single application generator. The
amount of productivity gained depends on the ease of addition, having an interpreter for GAL provides a
building the application generator and consequently on the prototyping environment.
approach to its design. Thus, we discuss productivity
5.2.2 Efficiency
measurements in the next section with respect to our
framework. Here we consider two measures of efficiency: object code
size and execution speed. Although designing an inter-
5.2 Our Framework preter is easier than designing a compiler, there are
In addition to the advantages obtained from the DSL significant losses in speed and size (compared to compila-
approach, there are several advantages demonstrated by tion). In terms of speed, interpreters are typically 10±100
GAL due to our framework of generator design. The times slower than compiled programs, and in terms of size,
experiment shows that the framework achieves automatic our GAL interpreter is 10 times larger than a typical driver
and predictable generation of efficient video drivers, and a in object code size. However, a benefit of using partial
high-level of reuse. GAL also demonstrates that the benefits evaluation is that we can regain the loss in efficiency.
of the two-level approach for analyses and multiple We used Tempo [11], a partial evaluator for C, as the
implementations are of practical value. program specializer used to translate GAL specifications to
abstract machine programs, and to produce an efficient
5.2.1 Reuse and Productivity implementation of the abstract machine programs. In order
The abstract machine for X Window device drivers consists to make a size comparison, we compared the object file
of 95 small C procedures totaling 1,200 lines. Implementing
the abstract machine has roughly the same difficulty level
TABLE 2
Lines of Code Summary

Fig. 3. An extract of generated S3 card profile.

THIBAULT ET AL.: DOMAIN-SPECIFIC LANGUAGES: FROM DESIGN TO IMPLEMENTATION APPLICATION TO VIDEO DEVICE DRIVERS... 373

sizes of the generated drivers to that of the hand-coded TABLE 3

drivers. On average, the generated driver is only 30 percent Performance Results
larger than the hand-coded one. One main difference that
lead to an increase in code size is that the hand-coded
drivers often use loops to access a block of contiguous
registers. GAL does not recognize when registers are
contiguous, although it could. A second difference is that
hand-coded drivers are not always careful about saving and
restoring all registers.
The speed of most of the device driver functions are
insignificant, as they are only called during configuration.
However, we picked three device driver functions used for
drawing lines and rectangles in hardware to benchmark
performance. Since the interpreter level of our framework is
guaranteed to be eliminated (see Section 2), we are only
separation of the abstract machine from the interpreter
concerned with the abstract machine layer.
allows analysis at the abstract machine level.
For comparison, we prepared three versions of the X
As an example, the GAL abstract machine includes
Window server for an S3 TRIO64V + video card on a
operations that allocate and deallocate temporary storage
Pentium PRO-200. Table 3 shows the timing results for the and operations which use the temporary storage. As long as
three servers. The S3 XAA server is the X Window server the operations which use the temporary storage are only
provided with XFree86 and the included hand-coded S3 used between a set of allocate and deallocate operations, we
device driver. S3 AM is the same server with a device driver can insure there will be no uninitialized pointer derefer-
which directly uses the abstract machine. Finally, S3 PE is ences. The analyses of partial evaluation are capable of
the same server using the abstract machine, but after partial producing a specification of all the programs that could
evaluation. The table shows the performance of these possibly be generated by the partial evaluation process.
servers for lines and filled rectangles of size 10 as measured From this, we can obtain a formal description of all possible
by the standard XBench benchmark utility.3 The table also abstract machine programs that could be generated, and
includes a percentage using S3 XAA as a baseline. can check that the operations are always generated in the
The table indicates that there is a loss of about 20 percent correct order. Thus, for the GAL system we can prove that
in performance from the use of the abstract machine. This uninitialized pointer dereferences will never occur. This
loss of performance can be contributed to error checking, description of the generation process may also be analyzed
interpretation, function call, and data copying overhead. for performance properties, for example.
Data copying is due to the need to communicate across The separation of the abstract machine and the DSL
abstract machine operations. The write operation includes provides an intermediate level at which analyses can be
error checking to ensure that if previous operations fail the performed and could allow analysis at run-time. In fact, this
resulting data is not written to the card. This is particularly separation corresponds to a standard technique of program
important because the card could otherwise be damaged. specification, which factors the verification process into two
Finally, the I/O operations require some interpretation of parts [3]. As an example of analysis at run-time, we may
their parameters to determine the type of I/O to perform wish to check that device access within a video driver is safe
and which addresses to use. Although directly using the (e.g., does not access the disk device). This cannot be done
abstract machine incurs this performance loss, the results until run-time because it depends on what devices are
for the S3 PE server show that the program transformations present at run-time. In this case, we might accept video
performed by partial evaluation are able to recapture all of drivers in abstract machine form and analyze the abstract
the performance loss. A majority of the error checking can machine at run-time. Partial evaluation can be performed at
also be eliminated using Tempo because often the opera- run-time [12], so the efficiency can still be recaptured. This
tions preceding write operations cannot fail, and thus error kind of analysis is not feasible on machine code or even Java
conditions do not need to be checked. Finally, the bytecodes due to their general purpose nature. In proof-
parameters which are interpreted to select the type of I/O carrying code [24], the burden of proof is put on the
to perform and used for address computation are known programmer and the proof is sent with the code to be
and eliminated by Tempo. Tempo also performs inlining verified (verification being easier), whereas here we make
and copy elimination which eliminates function call and the proof easier so that it can be done at run-time.
data copying overhead. 5.2.4 Multiple Implementations
5.2.3 Analyses The video device driver family also demonstrates a useful
application of having multiple implementations of inter-
Our framework for application generator design contributes
preters and abstract machines. In this domain, it would be
in two ways to the use of program analyses. The generation
desirable to have abstract machines for several architectures
process is predictable and can be analyzed, and the
and interpreters for different operating systems. For
3. A small size is used to ensure measurements are not dominated by example, Fig. 4 shows the situation where there are
hardware operations which are independent of the driver. implementations of interpreters for Microsoft Windows 95
374 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 3, MAY/JUNE 1999

hand-coded drivers to automatically generated device

drivers. Generated drivers are roughly one third larger
than hand-code drivers and perform equivalently in terms
of speed. Additionally, we give measures on expected reuse
benefits; GAL specifications are roughly a factor of 9
smaller than a driver hand-coded in C.
The techniques presented in this paper have also been
applied to the active networks domain [31]. In this work, we
have developed PLAN-P, a DSL for active networks. By
using techniques for run-time specialization, we have
successfully specialized PLAN-P programs at run time to
achieve the effect of a just-in-time compiler (JIT). Experi-
mental results show that the programs produced by the
run-time specializer incur no overhead in overall system
performance in comparison to using handwritten C code.
Furthermore, in comparison to Java, another mobile code
approach, the specialized program is twice as fast as an
equivalent Java program compiled with an optimizing off-
line byte-code compiler.
Although our framework significantly reduces the
development time of application generators, future work
could be done in this direction. Specifically, this approach
would benefit from a generator-specific reuse method that
would allow interpreters and abstract machines to be
constructed from reused composable parts. Additionally,
Fig. 4. Multiple Implementations. given the nature of DSLs, they are extended frequently to
adapt to new program requirements, and the ease of
and Linux/X11, and implementations of the abstract extension also needs to be considered for such language
machine for the Dec Alpha and Intel based computers. In components.
this situation, with the equivalent of two application Our implementation of the static analyses indicates that
generators (interpreter/abstract machine pairs), the same methods of quickly constructing static analyses should also
GAL specification can be used to generate four different be investigted (e.g., composable anlayses). This is more
device drivers. We have implemented the X11/Intel path of important for DSLs than GPLs, since static analyses are a
Fig. 4. major motivation of the approach.
For prototyping, we have also benefited from having a In this work we have presented an application of our
second implementation of the abstract machine which approach to a program family with existing family
simulates the abstract machine operations. The simulation members. To further validate the approach, it is also
records the values that would be written to the card by the important to study its application to a program family
real abstract machine. This is an important feature as some which is not pre-existing. In this case, the abstract machine
video adaptors can be damaged by writing inappropriate and DSL might be developed from the results of a domain
values to the card. analysis or a commonality analysis, such as FAST [15].

6 CONCLUSIONS AND FUTURE WORK APPENDIX A

Domain specific languages hold the promise of delivering A COMPLETE GAL EXAMPLE
high payoffs in terms of software reuse, automatic program Appendix B gives a complete listing of the GAL specifica-
analysis, and software engineering. In this paper we have tion for several models of S3 video adaptors. In this
presented GAL, an example of a complete DSL for a realistic appendix, we explain some of the constructs that were not
program family: video device drivers. We also demon- included in the main text.
strated the benefits of DSLs by showing how GAL raises the Although the various registers of video cards are
level of abstraction of device driver specifications and typically accessed using an addressing scheme, there is
identifying some analyses that can be performed on GAL sometimes a sequential procedure that must be followed to
specifications because it is domain specific. access some registers. The serial construct is used to
A further contribution of the paper is to validate our specify this kind of procedure (see listing). The construct
framework of application generator design by applying it to consists of a list of sequences of actions that should be
this program family to provide an implementation of GAL. performed on the ports to access the registers. Thus,
Since our implementation is based on partial evaluation, it multiple ports may be accessed during the procedure, as
provides a complete interpreter for prototyping device in the example. Each sequence consists of a port, an
drivers, but still automatically generates efficient device operation (<= write, <=> read/write, => read), and a
drivers. Efficiency is demonstrated with results comparing sequence of values for writes or registers names for reads
THIBAULT ET AL.: DOMAIN-SPECIFIC LANGUAGES: FROM DESIGN TO IMPLEMENTATION APPLICATION TO VIDEO DEVICE DRIVERS... 375

and read/writes. The actions in the sequence are performed register Control3 := svga(0x69);
from the first port to the last, from left to right in the
±±Serial registers (see Appendix A).
sequence. The mode (R read, R/W read/write, W write) to the serial begin
right of the sequence indicates whether this sequence misc[3..2] <= (3,- , -, -, -) W;
applies to reading the registers to writing the registers or seq(0x12) <=> (-, PLL1, -, -, -) R/W;
both. seq(0x13) <=> (-, PLL2, -, -, -) R/W;
seq(0x15)[5] <= (-,- , 0, 1, 0) W;
The serial construct in the example defines the registers
end;
PLL1, and PLL2. In order to write values to these registers
the construct would be executed as follows. Write 3 to
misc[3..2], write the value of PLL1 to seq(0x12), write ±± Define predefined fields
the value of PLL2 to seq(0x13), and finally, write 0, then
1, then 0 to seq(0x15)[5]. ±± Horizontal resolution fields.
The S3 specification also includes an example of a derived field HTotal := HOverflow[0]#std;
field, which is not discussed in the paper. This is a field field HEndDisplay := HOverflow[1]#std;
whose value is derived from one of the standard fields. In field HStartBlank := HOverflow[2]#std;
the example, StartFIFO is a derived field. Its value is set field HStartRetrace := HOverflow[4]#std;
whenever the graphics mode is set, and is based on the
value of HTotal, the horizontal resolution. The declaration ±±Vertical resolution fields.
indicates this with the from clause. field VTotal := VOverflow[0]#std;
The clockmap is used when a card has both fixed and field VEndDisplay := VOverflow[1]#std;
field VStartBlank := VOverflow[2]#std;
programmable clocks such as the S3 Trio cards. It indicates field VStartRetrace := VOverflow[4]#std;
which clocks are fixed and which are programmable. The
example for the S3 indicates that clock 0 and 1 are fixed,
clock 2 is not available (NA), and clock 3 is the program- ±±Virtual screen fields.
mable clock f3. The parameters MinPClock and MaxP- field LogicalWidth :=
Control2[5..4]#Offset scaled 8;
Clock are also related to clocks and specify the minimum
and maximum values that can be generated by the clock cases
(i.e., not all values of f3M, f3N1, and f3N2 are valid). for S3_928, S3_968, S3_TRIO32, S3_TRIO64
Finally, the operating mode access is used to lock an field StartAddress :=
unlock registers on the card. Control2[1..0]#Memory[5..4]#std;
for S3_80x
field StartAddress :=
APPENDIX B Control2[0]#Memory[5..4]#std;
for S3_864,S3_964
GAL S3 LISTING field StartAddress := Control3[4..0]#std;
for others
field StartAddress := Memory[5..4]#std;
±± List all cards/models supported by this end;
driver.
chipsets
S3_911, S3_924, S3_80x, S3_928, S3_864, ±± Define derived fields (see Appendix A).
S3_964, S3_866, S3_868, S3_968, S3_TRIO32, field StartFIFO from HTotal :=
S3_TRIO64; HOverflow[6]#StartFIFOr offset 10 scaled 8;

±± Define ports. ±±Special S3 flags that must be set for 256 color
port svga indexed := 0x3d4; graphics modes.
port seq indexed := 0x3c4; enable SVGAMode sequence is
port misc := 0x3cc, 0x3c2; Misc1[4] <= 1, Memory[3] <= 1;

±±Define registers. ±±Define standard parameters.

register Miscr := misc; param TwoBankRegisters := false;
register Slock := seq(0x8); param InterlaceDivide := true;
register Offset := svga(0x13);
register ExtChipID := svga(0x2e); cases
register ChipID := svga(0x30); for S3_911, S3_924
register Memory := svga(0x31); param RamSize := State[5] mapped
register State := svga(0x36); (0 => 1024,1 => 512);
register Lock1 := svga(0x38); for others
register Lock2 := svga(0x39); param RamSize := Se[7..5] mapped
register StartFIFOr := svga(0x3B); (0 => 4096,2 => 3072> 8192, 4 => 2048,
register Misc1 := svga(0x3a); 5 => 5120, 6 => 1024,7 => 512);
register Control := svga(0x42); end;
register Control2 := svga(0x51);
register HOverflow := svga(0x5D);
register VOverflow := svga(0x5E); ±± Define clocks.
376 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25, NO. 3, MAY/JUNE 1999

[7] J. Bosch and G. Hedin, eds., Proc. Workshop Compiler Techniques for
cases Application Domain Languages and Extensible Language Models,
for S3_TRIO32,S3_TRIO64 LinkoÈping, Technical Report 96-173, Lund Univ., Apr. 1996.
param NoClocks := 4; [8] S. Chandra and J. Larus, ªExperience with a Language for Writing
field ClockSelect := Miscr[3..2]; Coherence Protocols,º Proc. First USENIX Conf. Domain-Specific
param MinPClock := 135; Languages, Santa Barbara, Calif., Oct. 1997.
param MaxPClock := 270; [9] J.G. Cleaveland, ªBuilding Application Generators,º IEEE Soft-
field f3M := PLL2[6..0] offset 2 ware, July 1988.
range 1 to 127; [10] C. Consel, L. Hornof, J. Lawall, R. Marlet, G. Muller, J. NoyeÂ, S.
field f3N1 := PLL1[4..0] offset 2 Thibault, and N. Volanschi, ªTempo: Specializing Systems
range 1 to 31; Applications and Beyond,º ACM Computing Surveys, Symp. Partial
field f3N2 := PLL1[6..5] mapped Evaluation, 1988, to appear.
(0 => 1, 1 => 2, 2 => 4, 3 => 8); [11] C. Consel, L. Hornof, F. Nol, J. Noy, and E.N. Volanschi, ªA
clock f3 is 14318 * f3M / f3N1 * f3N2; Uniform Approach for Compile-Time and Run-Time Specializa-
tion,º Danvy et al., eds., Partial Evaluation Int'l Seminar, Dagstuhl
clockmap is (fixed, fixed, NA, f3); Castle, pp. 54-72, Feb. 1996.
for others [12] C. Consel and F. Nol, ªA General Approach for Run-Time
param NoClocks := 16; Specialization and Its Application to C,º Proc. Conf. Record of the
field ClockSelect := Control[3..0]; 23rd ACM SIGPLAN-SIGACT Symp. Principles of Programming
Languages, pp. 145±156, St. Petersburg Beach, Fla., Jan. 1996.
end;
[13] O. Danvy, R. Glck, and P. Thiemann, eds., Partial Evaluation,
International Seminar, Dagstuhl Castle, Lecture Notes in Computer
Science 1,110, Feb. 1996.
±± Identification procedure.
identification begin [14] C. Elliott, ªModeling Interactive 3D and Multimedia Animation
with an Embedded Language,º Proc. First USENIX Conf. Domain-
1: ChipID[7..4] => Specific Languages, Santa Barbara, Calif., Oct. 1997.
(0x8 => step 2, 0x 9 => S3_928,
[15] N.K. Gupta, L.J. Jagadeesan, E.E. Koutsofios, and D.M. Weiss,
0xA => S3_80x, 0xB => S3_928, ªAuditdraw: Generating Audits the Fast Way,º Proc. Third IEEE
0xC => S3_864, 0xD => S3_964, Symp. Requirements Eng., pp. 188±197, Jan. 1997.
0xE => step 3);
[16] N.D. Jones, ªAn Introduction to Partial Evaluation,º ACM
2: ChipID[1..0] => (0x1 => S3_911, Computing Surveys, vol. 28, no. 3, pp. 480±503, Sept. 1996.
0x2 => S3_924);
[17] N.D. Jones, ªWhat Not to do When Writing an Interpreter for
3: ExtChipID => Specialisation,º Danvy et al., eds., Proc. Partial Evaluation Interna-
(0x10 => S3_TRIO32, 0x11 => S3_TRIO64, tional Seminar, Dagstuhl Castle, pp. 216-237, Feb. 1996.
0x80 => S3_866, 0x90 => S3_868, [18] N.D. Jones, C. Gomard, and P. Sestoft, Partial Evaluation and
0xB0 => S3_968); Automatic Program Generation, Int'l Series in Computer Science,
end; Englewood Cliffs, N.J.: Prentice Hall, June 1993.
[19] S. Kamin and D. Hyatt, ªA Special-Purpose Language for Picture-
Drawing,º Proc. First USENIX Conf. Domain-Specific Languages
±± Register locks on S3 chips. Santa Barbara, Calif., Oct. 1997.
enable access sequence is [20] R. Kieburtz, L. McKinney, J. Bell, J. Hook, A. Kotov, J. Lewis, D.
Lock1 <= 0x48, Lock2 <= 0xA5, Slock <= 0x6; Oliva, T. Sheard, I. Smith, and L. Walton, ªA Software Engineering
disable access sequence is Experiment in Software Component Generation,º Proc. 18th IEEE
Lock1 <= 0x00, Lock2 <= 0x5A, Slock <= 0x0; Int'l Conf. Software Eng, ICSE-18, pp. 542±553, 1996.
[21] D. Ladd and C. Ramming, ªTwo Application Languages in
Software Production,º USENIX Symp. Very High Level Languages
ACKNOWLEDGMENTS New Mexico, Oct. 1994.
[22] R. Marlet, S. Thibault, and C. Consel, ªMapping Software
This work has been partially supported by France Telecom Architectures to Efficient Implementations via Partial Evaluation,º
Proc. Conf. Automated Software Eng., pp. 183±192, Lake Tahoe, Nev.,
under Contract No. CNET 96-1B-027 and by Defense IEEE Computer Society, Nov. 1997.
Advanced Research Projects Agency under Contract No. [23] R. McCain, ªReusable Software Component Construction: A
Product-Oriented Paradigm,º Proc. Fifth AiAA/ACM/NASA/IEEE
F19628-95-C-0193. Computers in Aerospace Conf., Long Beach, Calif., Oct. 1985.
[24] G. Necula, ªProof-Carrying Code,º Conf. Record 24th Symp.
Principles of Programming Languages, pp. 106±116, Paris, ACM
REFERENCES Press, Jan. 1997.
[25] J. Neighbors, ªSoftware Construction Using Components,º PhD
[1] B.R.T. Arnold, A. van Deursen, and M. Res, ªAn Algebraic thesis, Univ. of Calif. at Irvine, 1980.
Specification of a Language Describing Financial Products,º Proc,
[26] G.D. Plotkin, ªA Structural Approach to Operational Semantics,º
IEEE Workshop Formal Methods Application in Software Eng., pp. 6±
Univ. of Aarhus, Aarhus, Denmark, 1981.
13, Apr. 1995.
[2] J. Bentley, ªProgramming Pearls: Little Languages,º Comm. ACM, [27] R. Prieto-DõÂaz, ªDomain Analysis: An Introduction,º Software Eng.
pp. 711±716, Aug. 1986. Notes, vol. 15, no. 2, Apr. 1990.
[3] H.K. Berg, W.E. Boebert, W.R. Franta, and T.G. Moher, Formal [28] C. Pu, A. Black, C. Cowan, J. Walpole, and C. Consel,
Methods of Program Verification and Specification. Englewood Cliffs, ªMicrolanguages for Operating System Specialization,º Proc. First
N.J: Prentice Hall, 1982. ACM-SIGPLAN Workshop Domain-Specific Languages, wDSL'97,
[4] J.A. Bergstra and P. Klint, ªThe ToolBus Coordination Architec- Paris, Jan. 1997.
ture,º Proc. First Int'l Conf. Coordination and Models, Cesena, Italy, [29] T. Romer, D. Lee, G. Voelker, A. Wolman, W. Wong, J. Baer, B.
Lecture Notes in Computer Science, vol. 1,061, pp. 75±88, 1996. Bershad, and H. Levy, ªThe Structure and Performance of
[5] E. Bjarnason, ªApplab: A Laboratory for Application Languages,º Interpreters,º Proc. Seventh Int'l Conf. Architectural Support for
L. Bendix, K. Nrmark, and K. Sterby, eds., Proc. Nordic Workshop Programming Languages and Operating Systems, pp. 150±159, Oct.
Programming Environment Research, Technical Report R-96-2019, 1996.
Aalborg Univ., May 1996. [30] S. Thibault and C. Consel, ªA Framework for Application
[6] G. Booch, Software Components with Ada. Benjamin/Cummings, Generator Design,º Proc. Symp. Software Reusability, Boston, Mass.,
1987. May 1997.
THIBAULT ET AL.: DOMAIN-SPECIFIC LANGUAGES: FROM DESIGN TO IMPLEMENTATION APPLICATION TO VIDEO DEVICE DRIVERS... 377

[31] S. Thibault, C. Consel, and G. Muller, ªSafe and Efficient Active Charles Consel received his PhD degree from
Network Programming,º Proc. 17th IEEE Symp. Reliable Distributed the University of Paris 6 in 1989. He worked as a
Systems, West Lafayette, Ind., Oct. 1998. research faculty member for three years at Yale
[32] S. Thibault, J. Marant , and G. Muller, ªAdapting Distributed University until 1992. He then spent one year at
Applications Using Extensible Networks,º Proc. 17th IEEE Conf. Oregon Graduate Institute as an assistant
Distributed Computing Systems, Austin, Texas, May 1999. professor. He is now a professor of cmputer
[33] A. van Deursen and P. Klint, ªLittle Languages: Little Main- science at the University of Rennes 1. He leads
tenance?º Proc. First ACM-SIGPLAN Workshop Domain-Specific the Compose group at IRISA/INRIA. His group
Languages, wDSL'97, Jan. 1997. studies partial evaluation, a program transforma-
[34] First ACM-SIGPLAN Workshop Domain-Specific Languages, Paris, tion approach aimed at specializing programs
France, Computer Science Technical Report, Univ. of Illinois at with respect to given execution contexts. This work has been carried out
Urbana-Champaign, Jan. 1997. in practice with a program specializer for C called Tempo. This system
[35] B.W. Weide and W.F. Ogden, ªRecasting Algorithms to Encourage has been successfully used in various applications, such as operating
Reuse,º IEEE Software, vol. 11, no. 5, Sept. 1994. systems and scientific code. A complementary research project is
[36] The XFree86 Project, http://www. xfree86. org/. domain specific languages: a software engineering approach that
provides high productivity, easy maintenance and improved safety
Scott A. Thibault received the BS degree in (without giving up performance, thanks to partial evaluation). His other
computer science from the University of Vermont research interests include semantic program analysis, compilation and
in 1993; the MS degree in computer science compiler generation, programming environment, prototyping, program
from the University of Missouri at Rolla in 1995; transformation, and formal specification. His work on programming
and the PhD degree in computer science from languages, software engineering, and operating systems has led to
the Universite de Rennes I in 1998. He is many publications in major conferences and journals, such as: POPL,
currently founder and president of Green Moun- PLDI, OOPSLA, SOSP, ASE, TOPLAS, ACM Surveys, and so on.
tain Computing Systems, Inc. His current re-
search interests include the development and
application of domain-specific languages, net-
work security, and electronic-design automation. He has published four
conference papers in the area of domain-specific languages.

Renaud Marlet received his PhD degree in

computer science from the University of Nice-
Sophia Antipolis, France, in 1994. He is a
research associate scientist in the Compose
group at IRISA/INRIA-Rennes, France. His work
focuses on two facets of program adaptation,
i.e., the ability for a program to adapt to the
context in which it is used (using partial
evaluation and specialization declarations) and
the adaptation of programming to specific
domains or application families (by means of adaptable software
components and domain-specific languages). He is one of the co-
developers of Tempo, a partial evaluator for C.