Som v 2.4  (Children-day release 2007)

Development

It is a som-in-som interpreter/compiler system. It used som v 1.6 as a development platform.  som16 is an updated of som v 1.5 toward som17 to have "loadfile".  The idea here is to release som v 2.4 as an uptodate, stable version of Som for year 2007.  The goals for this version are:

1)  use simple s-code.
2)  improve interp.c for faster speed.
3)  has the following (of som16) : macro, static array, object with no immediate line, hex, file, and from som17, loadfile.
4)  make som-in-som as clean as possible.

Why not t-code?  From som17, I found that a lot of development time is spending on subtle bugs in code generator.  However, the speed improvement (in term of execution time) comes mostly from engineering the interpreter not the t-code itself. T-code which has 40%  number of instruction does not translate into 2.5 times faster in term of execution time (it is only 25% faster). So, the complexity of t-code does not worth it.  som v 1.8 is sort of closing down the experiment on t-code.

Step of work
1)  update som v 1.6 toward som v 1.7 (except using s-code instead of t-code).
2)  use som16 to write som v 2.4.

using som-v16 as the development platform som-v16 is used as the development platform for som-v24.  It is used to compile and run the whole som-in-som (som.txt).  som-v16 is a standalone compile&run program.  It can compile and run som.txt immediately.  Like this:
    c:>som16 som.txt < bubble.txt
It means, using som16 to compile "som.txt" then running it, the executable code is the som-in-som compiler which takes standard input as a som-source "bubble.txt", som-in-som compiler compiles "bubble.txt" and produces output to standard output (notwithstanding, "som.txt" must be written to take input/output accordingly).

However, when running "som.obj" it is not necessary to keep the data structure occurred during compiling "som.txt" (such as parse tree, symbol table, etc).  Therefore, we separate "compiling" and "running" the "som.txt".  Compiling "som.txt" will generate an executable "som.obj" without runtime data structure (read \doc\som-v23-reloc.txt for details).  Running "som.obj" will have all data segment free for use. The command line should be like this:
    c:>som16 som.txt
produce "som.obj" without runtime data structure.
    c:>som16 -c bubble.txt
use "som.obj" to compile and run bubble.txt

This way, som16 can be used both to compile som-v24 (som.txt) and to run som-v24, hence avoiding having inconsistent som-in-c source. Finally, when releasing som-v24, som16 can be modified to be "execute only" retaining only the interp.c and necessary support functions.  

This will make sure that the defined memory (in som16) is appropriate. som16 will be subsequently released for public as a
final version of som-in-c.  

som-v24 can be used as a future development platform, hence it frees som system from som-in-c.

Som-v24 features

Som v 2.4  has
1)  macro (similar to som v 1.5)
2)  hex   (similar to som v 1.7)
3)  loadfile  (similar to som v 1.7)
4)  file I/O
4)  static array

File I/O

The additional syscalls are:

: fopen fn mode = syscall {5 fn mode}
: fclose f = syscall {6 f}
: fprint f x = syscall {7 f x}
: fprintc f  x = syscall {8 f x}
: fgetc f = syscall {9 f}
: fgets f buf = syscall {10 f buf}

See the example of use of these syscalls in "test\file-s.txt".

To make som-in-som some additional syscalls are:
: load fn = syscall {15 fn}  // compile file fn
: eval a = syscall {12 a}    // start vm at a
: exit = syscall {13}        // abort current vm

"load" is connected to the function "loadfile" in som-in-som.

Static array

The static array from som v 1.7 is extended to include: number, identifier, and string.  A number occupies exactly one word. An
identifier occupies one word (it is the reference of that identifier). A string occupies the amount of length of string.

The use of string static array can be seen in "som\icode-s.txt" for storing the printing name of opcode. 

Creating som.obj

The whole som-in-som source consisted of the following files (in Som) (sequence according to the order of loading the file):

load "string-s.txt"
load "compile-h-s.txt"
load "list-s.txt"
load "symtab-s.txt"
load "token-s.txt"
load "parse-h-s.txt"
load "stmt-s.txt"
load "parse.som"
load "icode-s.txt"
load "gencode-s.txt"
load "macro-s.txt"
load "main-s.txt"

The file "som.txt" is the master file.  It can be compiled into "som.obj" as follows:
    c:>som som.txt

This will create som.obj and som.lst (the listing file).  This "som.obj" is the executable s-code of the som-v24 system.  (However
the object for som-v24 is "som0.obj", it is renamed to prevent overwriting by accident).  "som.obj" is self-compiled, that is the
som.txt is compiled into its own object.  Finally, the self-replicate property has been achieved in this release.  (that is "som.obj" is
exactly the same as "som0.obj").  The library source file is "lib2.som".

In terms of speed, som-v24 virtual machine has been engineered to be as fast as som-v17 (if not faster).

How to use som-v24

From the command line, these options are available:

    som          interactive mode
    som file     compile and run, output .lst and .obj
    som -x file  execute obj file
    som -?       for help

The object file is the same format as som-v2 except:
1)  magic cookie is 5678916  (som16 object)
2)  it includes symbol table with the form: (name type ref arity lv)

The initial file that must be presented when using som-v24 are: lib2.som and som0.obj.

12 Jan 2007
Tomorrow will be the children-day!