The main function of vm is "eval". It is written based on the C version
of som-v52 itself. In version 5.2, in eval, the call is improved by
simplifying the code, eliminating param[.] and arrange the passing
parameters on the stack segment (SS[.]). Two elements (first and second
parameters in M[1], M[2]) are in registers so the first two slots of the
new stack frame are spared. The new sp must start at the third slot (hence
the sp+2 when create a new frame). The code of "vm-s.txt" can be found in
the directory vm-som and here.
To be able to run and test vm-s.txt, a number of supporting functions are
written "initVm" (to initialise the memory of vm) and "loadObj" (to read
the object file). This vm can be run under som-v52. It reads an object
file and execute it (just like som52 -x obj). The name of the target
object file must be hard code into "loadObj" as there is no way to pass
this name from the outer C.
Once vm-s.txt is complete (it is tested on small programs such as
bubble.txt, quick.txt), the som-to-c converter is developed.
The som2c is a compiler that reads som source and converts it to C. It
is based on som-v52 som source. som2c is written and it is used to
convert vm-s.txt to vm.c. The major change of the code is in
"gencode-s.txt" (now "icode-s.txt" is not used any more). All sources in
this directory look like som compiler source (under som52). A number of
decisions are made about som2c.
1) it is not aimed to convert all features in Som, so it is not complete
as a general som to c converter. It is good enough to convert vm-s.txt
only.
2) The immediate execution of source (inteactive mode) can not be
handle. This includes the declaration of variables.
3) The "enum" is processed by som compiler on-the-fly so the
symbolic-names become integer literals. This made the output C more
difficult to read.
4) The dynamic allocation ("array") has not been convert. We have not aim
to deal with it. In the compiler, this allocation is made to declare array
variables.
5) Som string when convert to C has been made into C string. So, in a
few places this gives a conflict of types.
6) Som feature such at "tuple" (variable number of parameters) is
complicate to translate to C straightforwardly. So, in "syscall" we limit
it to fixed two-arguments. (because that is what vm-s.txt use)
7) syscall has ambiguous type as it can both be "void" and "int" because
some syscall returns values, some does not. This cannot be convert to C.
First, create som52 compiler. The directory vm2 contains vm in c for
som-v52 (v52 does not use lex2.c). This is "before" new "eval" (from
vm-s.txt) is integrated into the vm. This vm is used to develop other
codes.
1) som51 compiler is used to compile som2c. It produces som7.obj.
2) so to change som2c, first "makesom7" to recompile som2c to produce
som7.obj. If vm needs to be changed, compile vm in vm2. (for debugging
som2c purpose).
3) try som2c on small programs, try to compile (with C compiler) the
output C source. A file "header.c" is an additional C code included while
compiling the output. It is necessary and it contains variables
declaration and other initialisation code. Work on it until the output is
compiled correctly.
4) use som2c to create the new vm.c
The old "eval" function (in interp.c) is replaced by the new "eval" in
vm.c. The new vm.c must be manually edited in the following places:
1) comment out the functions: initVm, error, readNum, xsys. Those are
available in c file (in main file, som.c).
2) symbolic name MAXDS, MAXSS are edited back to replace the literals
because the actual value depends on C header file (compile.h).
3) compile.h has included a few declaration to make vm.c compiled without
warning messages. A few warnings are existed because all functions in som
are converted to "int" type but in fact some of them do not return value.
Happy coding with som-v52!
10 November 2012
(the 10-11-12 release)