Welcome to the Devil Homepage



Devil: A DEVice Interface Language

Devil (DEVice Interface Language) is an IDL aimed at providing the lower layer of a device driver, i.e., the basic interaction with the device. A Devil specification rigorously describes the access mechanisms, the type and the layout of data that are exchanged to operate the device, as well as some behavioral properties. It does not assume any particular OS, and can therefore be used for any target platform.


How to get Devil?

The present distribution contains the Devil compiler (named taz) as a binary and a set of specifications for testing it.
Please note that this release is an alpha version. There are many known limitations. NEW Source code of the Taz compiler released under LGPL.



Related Papers

Reference manual


How to use the taz compiler?

The taz compiler takes a Devil specification as an input and generates a C interface that implements this specification.
The following options can be used in the command line :
        -o filename  Set the name of the output file (defaults to inputname.h where inputname is the name of the input file)
        -nocode   Do not generate code, only verifications are performed
        -version   Display version information


How to use the generated C interface?

Suppose that we have the following Devil specification :
 
device foo (base : bit[8] port @{0..1})
{
  register cmd  = write base@0, mask '1011 0...' : bit[8];
  register stat = read base@1, mask '**** **..' : bit[8];
 
  variable command= cmd[2..0] : {
    ON    => '100',
    OFF   => '000',
    BLINK => '101'
  };

  structure status = {
    variable ready = stat[1], volatile : bool;
    variable died  = stat[0], volatile : bool;
  };
}


Once compiled, a C interface is produced from this specification. The following types, variables, and functions are defined :

The produced interface can be used in two differents modes, with references or without.
  1. With reference : (default) In this mode, all functions need a pointer to a device structure as a parameter. This mode is often used when the driver has to manipulate several devices. Here, is an example for using the C interface :
      1.  
        #include "foo.dil.h"
  2. Without reference : In this mode, the device structure is automatically allocated once, the new function is not created and each function is prefixed by the name of the device. This name can be modified with the dev_name flag. Functions get and set becomes :
  3. Here is an example for using the C interface in this mode and naming the targeted device as foo1
         
        #define DEVIL_NO_REF
        #define dev_name foo1
        #include "foo.dil.h"


For efficiency purpose, the generated interface can be used with 3 different levels of type safety


Real driver performances


In order to evaluate the benefit and impact of Devil in driver development, we are currently re-engineering various Linux drivers which run on recent bi-processor PCs installed in our group.1

IDE Driver

Table 1 presents a performance comparison of a Devil-based IDE driver against the original C driver. Throughput measurements were obtained using the standard Linux hdparm utility. Two Devil specifications have been written for this driver: a specification of the IDE controller and a specification of the Intel PIIX4 PCI busmater IDE.

We have run the IDE driver in both Ultra DMA-2 and several PIO modes, varying the size of I/O (16 or 32 bits) and the number of sectors transfered per interrupts. In DMA mode, Devil induces 6 additional I/O operations to prepare the command. Because of the duration of the DMA transfer, there is no impact on the available throughput. In PIO modes, there are 3 additional I/O operations to prepare the command, plus 2 for each interrupt (#s denotes the total number of sectors of the access). On specific processors such as those of the Pentium family, replacing a C loop over a variable read/write by a dedicated looping instruction (e.g., rep) is often more efficient. This situation can be found for the Programmed I/O (PIO) transfer mode of the IDE Linux driver; using a C loop induces a 10% throughput penalty.

 
  Standard driver Devil driver  
Transfer
mode
Sectors
per
interrupt
I/O
Size
in bits
I/O
Operations
Throughput
in Mb/s
I/O
Operations
Throughput
in Mb/s
Devil/Stand.
throughput
ratio
DMA - - 14 14.25 20 14.25 100 %
PIO 16 32 7+#s(1+128)/16 8.17 10+#s(3+128)/16 7.36 90 %
16 7+#s(1+256)/16 4.45 10+#s(3+256)/16 3.94 88 %
8 32 7+#s(1+128)/8 8.09 10+#s(3+128)/8 7.28 89 %
16 7+#s(1+256)/8 4.42 10+#s(3+256)/8 3.91 88 %
1 32 7+#s(1+128) 6.93 10+#s(3+128) 6.36 91 %
16 7+#s(1+256) 4.06 10+#s(3+256) 3.63 89 %

Table 1: IDE Linux driver comparative performance results

X11 Driver

Tables 2.1 and 2.2 present a performance comparison of a Devil-based X11 driver against the original C driver. Throughput measurements were obtained using the xbench utility.

An X11 driver is a module which is built into an X11 server. Unlike most Linux drivers, an X11 driver is therefore not a kernel module : it runs in user-mode. In our experiment, we used the 3DLabs-dedicated server from the popular Xfree86 implementation of X11 (version 3.3.6). This server includes a driver for 3DLabs' Permedia2 graphics controller. Although this chip provides acceleration for both 2D and 3D, the X11 server does not take advantage of 3D. Moreover, to minimize hardware-dependant code, the server implements many 2D primitives in software. Hardware acceleration is only used for the two most time-consuming primitives : filled rectangle and screen area copy. Tables below present results for both of these accelerated primitives.

The number of drawn pixels and the depth (number of bits) of each pixel influence the completion time of a primitive. Indeed, the higher these figures are, the more video RAM is accessed, and the busier the graphics controller is. Since the CPU is only used for triggering the controller, driver optimization is more important when primitive calls are light and quick. We therefore conducted tests in various contexts, and the slight CPU overhead introduced by Devil showed only for the lightest calls. For primitive calls involving at least 100 pixels (which are the most common in pratice), 99% to 100% of the speed were retained (always 100% at 24 bits, the most common depth). For the tiny 4-pixel calls, results ranged 94%-100% (97%-100% at 24 bits). We therefore can conclude that using Devil in this driver did not introduce any significant performance penalty.

Note : Due to the programming model of Permedia2, the driver must wait (busy loop) for free entries in an on-chip FIFO before accessing the chip. Such loops take one I/O per iteration. In the tables, the number of I/O operations is given with a w variable, which is the average number of I/Os per waiting loop. For example, 3w + 15 means that the driver performs 3 waiting loops, plus 15 useful I/Os.

 

 
Standard Driver
Devil Driver
 
Display Mode
(bits/pixel) 
Rectangle Size
(pixels) 
I/O
Operations 
Troughput
(rectangles/s) 
I/O
Operations 
Troughput
(rectangles/s)
Devil/Standard
Troughput Ratio
8
2 x 2
3w + 15
984838
3w + 17
949052
96 %
10 x 10
589621
585350
99 %
100 x 100
38472
38438
100 %
400 x 400
3762
3762
100 %
16
2 x 2
3w + 15
982338
3w + 17
945916
96 %
10 x 10
333670
332499
100 %
100 x 100
21022
21033
100 %
400 x 400
2221
2221
100 %
24
2 x 2
2w + 10
978605
2w + 10
945884
97 %
10 x 10
235119
234716
100 %
100 x 100
3693
3693
100 %
400 x 400
244
243
100 %
32
2 x 2
3w + 15
957534
3w + 17
929833
97 %
10 x 10
251522
251584
100 %
100 x 100
10466
10466
100 %
400 x 400
899
899
100 %

Table 2.1 : Comparative Performance of Permedia2 Xfree86 Driver : Rectangle Test


 
Standard Driver
Devil Driver
 
Display Mode
(bits/pixel) 
Copy Size
(pixels) 
I/O
Operations 
Troughput
(copies/s) 
I/O
Operations 
Troughput
(copies/s)
Devil/Standard
Troughput Ratio
8
2 x 2
3w + 15
149553
3w + 17
144494
97 %
10 x 10
123584
122300
99 %
100 x 100
10662
10638
100 %
400 x 400
764
764
100 %
16
2 x 2
3w + 15
145084
3w + 17
136755
94 %
10 x 10
85994
85561
99 %
100 x 100
3502
3512
100 %
400 x 400
238
238
100 %
24
2 x 2
2w + 9
144385
2w + 9
144521
100 %
10 x 10
77443
77605
100 %
100 x 100
1716
1716
100 %
400 x 400
114
114
100 %
32
2 x 2
2w + 9
142335
2w + 9
142598
100 %
10 x 10
69762
69804
100 %
100 x 100
1703
1701
100 %
400 x 400
111
111
100 %

Table 2.2 : Comparative Performance of Permedia2 Xfree86 Driver : Screen Copy Test



1

 The PC is a DELL Precision 210 with the following configuration: two Pentium II 450 MHz, Intel PIIX4 PCI chipset, Maxtor model 91000D8 UDMA2 19.5Gb disk (512Kb cache), 3DLabs Permedia2 Graphics Controller.


Contact the Devil development team

Bug reports and messages can be send to the Devil development team: devil@labri.fr
The Devil mailing list devil-users@labri.fr: subscribe to devil-users@labri.fr (send the message "subscribe devil-users@labri.fr" to majordomo@labri.fr).

Last modified: jeudi, 25-sep-2003 16:25:24 CEST - Laurent.Reveillere@labri.fr