Som release history

4 Dec 2004	som-v1	first public release
31 Dec 2004	som-v2	second public release (with som-in-som)
26 June 2005	som-v1.5	with macro and tail-call
5 Jan 2006	som-v1.7	with new VM, T-code
23 Dec 2006	som-v1.8	bug fixed v 1.7, T-code
12 Jan 2007	som-v2.4	Children-day release (som-in-som for 2007)
9 Mar 2007	som-v3	som-in-som with sx-code vm
19 Aug 2007	som-v3.1	fast sx-code vm
2 July 2008	som-v4.0	fast u-code vm
9 Aug 2008	som-v4.1	Birthday release (improve u-code and compiler)
9 Sept 2009	som-v4.2	Triple 9 release (lex in vm)
22 Sept 2009	som-v4.2a	bug fix interactive mode (new parser)
5 Dec 2009	som-v5	T2-code vm (Long Live the King)

History

som0 (first integration of som, A1a+A1sm)

13 September 2003
This implementation aims to separate compiling into an executable sequential code for a virtual machine and generating machine code for a machine specific processor. This is similar to compiling a source program into icode which can be executed, and then use it to generate S2 assembly language for S2 processor.

For an executable sequential code, the emphasis is on a small number of instruction, and ease of modifying this set. The icode for Som which will be called s-code, should be reasonably fast when interpreting, and easy to generate machine dependent code. Many code generators can be aimed for specific purpose, such as, small code size (byte-code, nybble-code), high speed (extended code), or to fit a particular hardware. Therefore, the optimisation should not be emphasise. Instead, a "clean" implementation is the goal, so that, it is easy to modify or to make a new code generator.

A fixed 32-bit instruction is suitable (not compact but easy to generate code and reasonably fast when interpreting). The instruction set is of A1a but eliminates some extended code.

som-som (start of som-in-som)

26 Decenber 2003
This project's goal is to start a boostrapable system that eventually will be written in som itself. The starting system is written in C and gradually it is replaced by Som. The system is divided into three parts: a parser, a code generator, a virtual machine. The parser transforms a source (Som program) into an abstract program (parse tree). The code generator generates S-code from this parse tree. The virtual machine executes S-code. This division makes the system easy to understand. The parser separates the handle of two domains, one is the charactor domain represented the source program, and the other is the token (integer) domain represented the abstract program. The token is suitable for Som-language. It makes the code generator and virtual machine easy to be written in Som. The virtual machine has been written in A1a (the precursor of Som). The parser and code generator are integrated in the current system (som, som1). Separating them into two parts enables the code generator to be written in Som easily. It may not be interesting to write the parser in Som, as there are tools for parser generators, which accept the input as a grammar and output a parser in some high level language program. It is possible to translate the output from these tools into Som language.

29 Jan 2004 Implement parser generator to generate parse.som

12 Feb 2004 Add tuple to som-language to handle variable arguments to a function. Use it for syscall. (this design eliminate the open stack coding)

som-v1

4 Dec 2004
This is a reference system for Som-language. It is som3 released to public. The major change in som3 is that it can do recursive load and has a good interactive mode. Effort will be made to document this release so it is understanble for the public (mainly students and my research assistances).

som-v2

31 Dec 2004
This version is an evolution of Som system to be self-replicating. That is the system can generate itself with minimum support from a host language. This is achieved by writing most of Som system (lexical analyser, compiler, code generator) in Som. Only the eval function must be written in the host language (C). This approach has been used to port a compiler to a new platform since the early days of computer science, for example, Pascal compiler. However, the interesting point is not "porting" a system to another platform. It is the ability to "self-replicate" that I try to achieve.

This Som system comprises of the whole Som in object format (som-code, "som.obj") that is loaded into the memory and is executed by eval() (written in C). This image plus eval-in-C works as Som compiler. The first image "som.obj" is generated by Som itself. However, this is not done in this release. The present "som.obj" is generated from a modified Som v1. There are minor differences that are needed to be resolved before it is truely self-replicate.

som-v1.5

26 June 2005
Som with macro and proper tail-call. Modify som v1 to include macro, a bit of jump improvement (jle for "for") and perhaps hash from symtab5 (from som-in-som, som-v2). (23 Feb 2005)

1 macro
2 jle
3 eliminate callt
4 retv
5 hash symtab

Aim is to improve performance when it goes to a real chip. (prepare for vy1)

Som v 1.7

23 December 2005
It is going to be new year soon! I have a great new idea on er... a new VM for som, called T-code. T-code will be a register based VM as opposed to s-code. As T-code is 3-address format, it will have less number of instruction executed (dynamic instruction count) than s-code. The data from various chip designs pointed to 40% noi. of s-code [aisd eecon 2003, sr, compact code jcsse 2005, xs]. This means if all else is equal, T-code vm will be 2.5 times faster than s-code.

Therefore, I will try to have a new year release of Som-v17 with T-code (a major release every year, eh?). Som-v17 will be a som-v16 (which never made public): macro, static array, new object, no immediate line, hex, file.

Som v 1.8

23 December 2006
This is a bug-fixed version of som-v17. Most bugs are in the code generator. "gencode.c" has been heavily rewritten. There is still some code sequence that is not optimised but it is correct. It has been tested and passed all benchmarks in "test" directory.

The macro has been fully debugged as well, especially the "full" macro.

Some optimisation has been implemented:
1) strength reduction, preprocessing literal arithmetic
2) lit k, mov v RETVAL --> movi v #k when k is 16-bit

This version is used to develop som-v23 (som-in-som in progress). som-v23 can compile and generate code correctly including all macros. The "eval" is being developed. So, som-v18 has been subject to extensive test to run som-v23 (around 2500 lines of som-code) except the "eval" part. som18 can do "load", see an example in "bubmat.txt".

som v 2.4 Children-day release

12 January 2007
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.

"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. In terms of speed, som-v24 virtual machine has been engineered to be as fast as som-v17.

som v 3.0

9 March 2007
This is a new release based on sx-code. Sx-code is zero+one-address instruction set. It is 30% faster in terms of number of instruction and running time than s-code. It is not complex, only larger than s-code (85 instruction vs 40). The added instructions are local-var mode and immediate mode of bop s-code pluses some "for performance" code such as efor. The virtual machine of som-v16u is used as VM for som-v3. This VM has been carefully engineered. It is the fastest VM for s-code family to date.

som v 3.1

19 August 2007
It is a continuing development of Som v3 with an improved vm. The new vm had fully-decode opcode and argument. It also employs a few techniques to speed up the execution of sx-code. The new vm is 40% faster than the old one (or 1.7x). The new vm has the following characters:

1. op and arg are fully decoded (no decoder)
2. use tos register (need a few special codes)
3. all jumps are absolute
4. faster access to local variables

The disadvantage is that the size of code segment is double (as xop[.] and xarg[.] are two arrays replacing cs[.] ). The object file format is changed. The compiler itself has also been improved. The symbol table is changed to be more space efficient. It is also better tuned (now with only 1/3 probing of the previous version). The listing generation is much faster as it employs "index" to the symbol table instead of requiring to search for a symbol by a reference. I found out that the meaning of a full macro and a normal macro are different. Therefore I decide to adopt only one meaning. A normal macro is much more useful, hence the full macro is discarded.

som v 4.0

2 July 2008
The 2007 series of Som are very exciting (Som v3.0 and Som v3.1). They are fast with new instruction sets and improved compilers. With their performance comes the complexity. The sx-code of som v3.1 has 93 instructions and it needs a complicate code conversion to make use of tos register. I want to retain performance of 2007 series but I really want to make the instruction as simple as the original s-code (at least in terms of the number of instruction). To this goal I design an accumulator-based instruction set with one-address format.

Som v4.0 uses the new vm based on u-code. It achieves two objectives:
1) u-code instruction set is as simple as the original s-code. It has only 43 instructions with consistent format.
2) The compiler is much simpler than Som v3.1 and it produces a fast code. It is 32% faster than som v.3.0. It is comparable to som v.3.1. However v3.1 is 10% faster.

som v 4.1

9 Aug 2008
Som v.4.1 uses the improved instruction set. The new instruction set includes the immediate mode and a few AC-arg instructions (to use AC as the argument for the next instruction, mostly load index). The expectation is to reduce the noi by 10-20% and also the running time comparing to som v.4.0. The compiler has gone through several improvements and it is better than the previous version (it is faster and produces better code).

Upon analysing v4 vs v31 compiler many possible improvements to u-code come to mind. The first is the immediate mode. The second is to use "cascade" AC to reduce "put" (using AC as argument in some instruction). However, adding everything will make u-code unattractively large. The aim to include more instruction into u-code is to improve the performance without undue increase in complexity to the instruction set.

In general benchmark, u2 does not improve much over u-code of som v.4.0. It is only 6% less noi. The running time speedup is only 8.7%. However, most improvement is done by analysing the compiler, to this end, the compiler benchmark is much improved. The noi of v4.1 compiler is 20% less than v4. The running time speedup is insignificant (may be due to heavily i/o bound?).

som v 4.2

Triple 9 release ( 9/9/2009)

This is a small experiment on lex. Lex is implemented as a built-in function (via syscall 16). The hope is that this will accelerate the compiler. lex2.c is written based on token-s.txt (lex in Som). An experimental version is lex0.c. It has a better buffering. However, it is more complex. lex0.c uses buffering to reduce the number of fread() call. lex2.c reads one line at a time. It is quite interesting to see how the new lex is interfaced to the old token-s.txt in a simple way.

In terms of performance, v42 noi is 78% of v41 (or 22% faster) but the runtime in similar.

som v 4.2a

22 Sept 2009
Fix interactive mode. Som 4.2a is som 4.2 (triple 9 release) with correction to lex that enables it to run in interactive mode. After two or three years of comtemplation, I decide to write a new parser generator. A lot of code is borrowed from Som compiler herself. The parser generator is about 700 lines of Som. The new parser is faster than the original one. In terms of performance, it is 30% faster than v4.1 (noi) and 11% faster than v4.2 (noi).

som v 5.0

5 Dec 2009 Long Live the King
This release has the goal to do "the fastest vm". To reach this goal, the vm uses three-address instruction format (t-code, som v 1.8) because it offers the lowest number of instruction executed (noi). Therefore in terms of performance, the noi will be smallest amongst all previous Som releases. Because running time is directly varied with noi, it will also be "the fastest som". This work is based on Som v19 series of experiments.

T2-code is introduced. In terms of performance, it is 40% less noi than v4.2. The runtime is 10% faster than v4.2.

last update 5 Dec 2009