som v 2.4

It is a som-in-som based on an updated version of som v 1.6 (which never release to public).  som16 is updated 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, to allow it to be used for Chip development.
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), called it som16a.
2)  use som16a to write som v 2.4 by changing som v 2.3 (som-in-som based on som17) to be based on som16a.

using som-v16a 

som-v16a is used as the development platform for som-v24.  It is used to compile and run the whole som-in-som (som.txt).  som-v16a is a standalone compile&run program.  It can compile and run som.txt immediately.  Like this:
	c:som16a som.txt < bubble.txt 
it means, using som16a 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:som16a som.txt
produce "som.obj" without runtime data structure.
	c:som16a -c bubble.txt
use "som.obj" to compile and run bubble.txt

This way, som16a 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, som16a 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 som16a) is appropriate. som16a may be subsequently released for public as a final version of som-in-c.

How can I use som-in-som as a development platform for future version? (so that there will be no more som-in-c).

3 Jan 2007
 