#summary About the Gigamos directory

= Introduction =

After LMI went bankrupt, its assets were bought by Gigamos Systems.  The new management changed the direction of the K-Machine project.  The files in the [http://jrm-code-project.googlecode.com/svn/trunk/gigamos/ Gigamos] subdirectory are ones that I believe were written after the buyout.


= Details =

The Gigamos effort was doomed to fail.  Guy Montpetit, the owner of Gigamos, was secretly bribing Canadian Senator Michel Cogger in order to get favorable contracts from the Canadian government.  When the corruption was exposed, Gigamos was shut down and its assets siezed.  But I think some fundamental problems would have prevented the project from finishing anyway.

The first, and largest problem was the change in vision.  When LMI was bought out, Bruce Deffenbaugh and I, the last of the two original architects, left the project.  Rick Greenblatt became the project leader.  Our vision was of a revolution; his was of evolution.  This lead to some changes that I think were serious mistakes.

First was discarding the new compiler.  Pace, Bruce, and I felt that the Lisp Machine compiler (QCOMPLR) was poorly suited for the K-Machine architecture.  We chose to adapt the Orbit compiler from Yale University and retarget it to the K-Machine.  This turned out to be harder than we had thought, but not impossible.  While we were not at the point of handling the entire Common Lisp language (let alone ZetaLisp), we could compile most of the benchmarks and certainly had enough of the new compiler working to develop code with.  Most of the low-level code that I wrote took some advantage of the Orbit compiler's ability to efficiently compile closures.

Rick retargetted QCOMPLR to the K-Machine.  He was successful in getting the compiler to generate code, but there were two large problems to overcome.  First, the code generated by QCOMPLR was significantly inferior to the code generated by Orbit.  This isn't surprising because QCOMPLR was designed for a virtual stack machine (like the Lambda) and Orbit was designed for a register machine (like the K-Machine).  The QCOMPLR code was about 1/2 to 1/3 as dense as the Orbit code, and this was reflected in the benchmarks taking much longer.

The second problem was the low-level code I had already written.  As I mentioned above, I took advantage of the compiler's optimizations.  QCOMPLR didn't have the analysis phase that made it possible to remove the closure creation code.  Needless to say, it is hard to take interrupts if the interrupt handler needs to cons a closure.

Rewriting the low-level code wasn't immediately feasible, so Rick had to maintain _both_ compilers during the bootstrap development phase.

The second serious mistake, in my opinion, was attempting to port the Lambda microcode.  Our intent was to discard the Lambda microcode.  The microcode was far too obscure and only a tiny number of people could effectively program in it.  In addition, the K-Machine was designed to not need a microcode emulation layer.  We expected to program the low-level functionality of the K-Machine directly in compiled Lisp.  Admittedly, this meant rewritting a large body of code, but we felt the advantages were worth the effort.

The Lambda microcode does not directly map onto the K-Machine architecture.  There are differences in functionality, register sizes, data path sizes, etc.  Porting the Lambda microcode is not so much transliteration as it is a rewrite in itself.  Nonetheless, it appears that was the approach that Rick favored.

The final serious mistake was attempting to design the next-generation hardware as a VLSI chip before the first-generation hardware had even made it to market.