Re: Window system

># From nick@nsis.cl.nec.co.jp Fri Oct 22 10:17:36 1993
>#
># After some thought, for better, or for worse, I have decided on the
># following points:
>#
># 1) Messaging will be in scheme, or a lisp dialect. This means messages
># from the application to MADO, and message from MADO to bitblt.
>#
># 2) MADO will have a built in widget set. They will be compiled into
># the server.
>#
># 3) MADO must be able to run within itself (ie. it will provide a
># compatible superset of the language to applications).
        **** I do not understand this point ****
>#
># 4) The system should be able to generate user-defined events.
>#
># 5) Is lisp proves expensive, I might use an assemblerish labguage I
># designed for my son (it's kind of a turtle graphics language),
># or I might remove the general programming language idea entirely.
        **** please keep the server programmable! ****

I agree with all these choices. (i don't know yet about MADO or VSTa,
but i'm the guy who posted a long NeWS description 2 days ago).

Perhaps you could have a look into scheme48-0.22 (it is still a Beta
version, but it works fine), by Richard Kelsey and Jonathan Rees
(MIT). You can ftp it from altdorf.ai.mit.edu:/pub/jar (files
scheme48-0.22.tar for the program, and lsc.ps for a draft of a paper in
Lisp & Symbolic Computation which describes it). Email to Jonathan Rees
at jar@altdorf.ai.mit.edu or jar@cs.cornell.edu for more details. He
considers scheme48 in early beta stage, but i find it more usable, and
much faster, that scm or siod.

What is scheme48? It is an implementation of IEEE (or R4RS) scheme. It
main features are:

        * a powerful module system, inspired from SML modules.
        
        * an efficient bytecode virtual machine interpreter. Its
          executes templates (bytecode fragment + array of scheme objects).

        * a scheme compiler, written in IEEE scheme, and producing
          bytecode templates executed by the virtual machine. So a scheme
          program is first compiled into bytecode and then executed.

All of scheme48 is written in scheme dialects, including the bytecode
virtual machine interpreter (hence also the runtime system, eg garbage
collector). This interpreter is written in PreScheme which is compiled
into C (once for all).

The scheme48 virtual machine is rather small:
Under my SunOS5.2 sparc machine (and compiled with gcc2.4.5. -O2)

 size -Ffn scheme48vm scheme48vm.unstripped
scheme48vm: 17(.interp) + 1616(.hash) + 3056(.dynsym) + 1987(.dynstr)
         + 24(.rela.bss) + 564(.rela.plt) + 88(.init) + 30852(.text) + 12(.fini)
         + 1952(.rodata) + 8(.ctors) + 8(.dtors) + 6(.rodata1) + 616(.plt)
         + 8(.data) + 12(.got) + 160(.dynamic) + 1804(.bss) + 207(.shstrtab) + 818(.comment) = 43815
scheme48vm: 160(r-x) + 17(r--) + 40354(r-x) + 2604(rwx) + 160(rwx) = 43295

scheme48vm.unstripped: 17(.interp) + 1616(.hash) + 3056(.dynsym) +
1987(.dynstr) + 24(.rela.bss) + 564(.rela.plt) + 88(.init) +
30852(.text) + 12(.fini) + 1952(.rodata) + 8(.ctors) + 8(.dtors) +
6(.rodata1) + 616(.plt) + 8(.data) + 12(.got) + 160(.dynamic) +
1804(.bss) + 3968(.symtab) + 2537(.strtab) + 256(.stab.indexstr) +
36924(.stabstr) + 207(.shstrtab) + 144(.stab.index) + 818(.comment) +
83424(.stab) = 171068
scheme48vm.unstripped: 160(r-x) + 17(r--) + 40354(r-x) + 2604(rwx) + 160(rwx) = 43295

-rwxr-xr-x 1 basile group_ia 43076 Oct 22 10:23 scheme48vm
-rwxr-xr-x 1 basile group_ia 170568 Oct 22 10:23 scheme48vm.unstripped

  wc *.[ch]
     479 1546 12866 dynload.c
      27 58 501 error.c
     317 1056 8050 extension.c
     146 471 3637 main.c
      35 156 1024 prescheme.h
      54 212 2003 scheme48.h
    6747 22962 212430 scheme48vm.c <<<< this file is made of C generated by a PreScheme compiler
       6 10 58 test.c
     327 909 7516 unix.c
    8138 27380 248085 total

I think that the main advantage of a bytecompiled scheme implementation
for a window system (MADO) is that:

The programmer codes MADO server application-specific code in high
level language such as scheme.

He/she compiles it into scheme48 bytecode image.

At run time, the application downloads the scheme48 bytecode image into
the MADO window server. Since it is a simple bytecode, its
interpretation is fast (probably as fast as a very simple stack
language), and faster that simple interpretation of scheme code
represented by lists (as SIOD or SCM are doing).

So this approach, in contrast to NeWS programming I discussed in an earlier post,

        is easy to program (because Scheme is higher level than PostScript or Forth)

        is efficient to execute.
        
In comparaison, scm4c0 is more that 4 times larger than scheme48
virtual machine. Of course, the full initial memory image of scheme48
(including compiler, command interpreter) is quite large (838kbytes)
but a window server nevers needs such a full system (i don't want to
compile to bytecode inside the window server!), and i suppose that a
small application specific server library would be much smaller
(30-300kbytes?).

Ultimately, it would have been interesting to have a real compiler for
bytecodes (ie to have a common, plateform independent, intermediate
bytecode which would be compiled at load time in the server into target
machine code), but i'm not sure that this technology is easily
availabel today. the OSF ANDF proposal is something in that way, but i
don't think it is running today.

Also, i think that for efficiency and evolution reasons, dynamic
loading of machine code extension (ie of a shared library prodced by a
C compiler) is a must while prototyping MADO. You don't know exactly
what common features should be programmable (in scheme or whatever
language you choose) and what other features should be wired into the
window server.

Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique
DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France
fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66
email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53

N.B. Any opinions expressed here are solely mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.
Received on Fri Oct 22 03:27:01 1993