
"Gerl - Geoff's Erlang"
~~~~~~~~~~~~~~~~~~~~~~~

Requirements
~~~~~~~~~~~~

Must have:

1. GNU Make
2. GNU C/C++ Compiler (gcc).

Preferably:

3. Autoconf

Building 
~~~~~~~~

Currently the system is setup as a development distribution; 
the following will help you.

1. After initially fetching (& unpacking) the source you should 
    ./configure
    make

    Note: ignore bad_exports, and bad handle errors compiling these.
          This is a bootstrap issue.
          This occurs because there is no "bif.so" before compiling bif.erl

2. Set your LD_LIBRARY_PATH to include to the lib/ directory and 
    the erlib/ directory.

3. Set your PATH variable to include the bin/ directory.

4. Edit 'bin/ecc' to contain the correct path information.
    [ FIX: actually should be done by autoconf? ]

5. Start an erlang node running:
    lib/enode 11111 &
    [ FIX: should happen automatically if it isn't running already ]

6. Test by:
    gerl 'reverse:reverse("testing 1 2 3")'

You should now be able to compile Erlang programs 
(subject to outstanding problems in 'TODO').


geoff@serc.rmit.edu.au


Erlang (to C) Compiler
~~~~~~~~~~~~~~~~~~~~~~~

As a primary feature of Erlang is its management of multiple processes
as a fundamental part of the system we need to plan for this early
in the construction phase.

I rely on the Unix process support (sockets and Unix communications 
between machines: ipsockets) to support multiple 
processes. To do this each process will need to be linked to a library
which provides packages communication support.
Processes will communicate via sockets in /tmp (or internet ports) with
there Unix pid as the socket identifier. This (with the machine id)
will be the identifier that gets created when a processes is spawned.
Ideally we'd like to be able to extend this to take advantages
of lightweight process support (so we're not limited to 32 processes).

This library will also contain other support code for Erlang
internals such as list and tuple management.

The actual compilation will take place in a number of phases --
1. Lexing/parsing - this phase will produce an abstract syntax tree.
2. Optimisation - break the tree into basic blocks for local expression
   optimisation. Try "global" (within a module) optimisation; also
   do (importantly) "last call optimisation".
3. Code production - this is essentially the transformation of the 
   tree into C code.
4. The C compiler then performs other optimisations etc.

It'd be really nice if the step 2-3 could be done into the backend
of lcc or gcc so we'd have automatic debugging support.

The primary motivation for doing all this is so we can built our own
quality monitoring tools. Initially we will try providing
this support by modifying the compiler to automatically spawn
a monitoring process for each process created in the system
(this will definetly challenge the Unix process limit).

Of particular difficulties include --
+ Providing incremental garbage collection over a number of 
  independent objects!
+ Providing for transparent updating of processes.
+ Trapping system signals as errors.

I'll also deviate slightly from the defined Erlang standard by
providing type-checking where possible (although it is limited;
extra syntactic support would make it quite worthwhile) - this
importantly increases early error detection and can speed
execution.

Testing The System
~~~~~~~~~~~~~~~~~~

I'd like to build a simulation of the GSM phone system which
will run on both a "standard" Erlang compiler (as provided by
Ericsson) and the one I'm building. Then attempt to do some
basic quality monitoring on the simulation (using our compiler)
and provide the equivalent code (by hand) to the system using
the standard Erlang compiler. 

This testing will provide information on the performance of
Erlang and on the efficiency of quality monitoring (monitor
performance degradation). Of course this will be
done primarily under Unix initially; this will then have to be
migrated to a more appropriate test target.

