When I started this blog, I did not know yet that I would do something completely different from 2010 to 2012. In the summer of 2010, I decided to get my MSc degree in Electronics/ICT, what would be the closest that I could get to a degree in software engineering. An additional benefit was that I also got a fairly thorough introduction into VHDL. I used this with this board to also build my master's thesis (there weren't any interesting topics in SE, unfortunately).

Last week I got my degree then officially.

Since a week or two I have been coding a simple environment for encoding S-expressions. It currently consists of the following parts:

• A system for managing cells. Each cell is either a CONS or part of a string. All cells are consistently 4 bytes in size. There are two functions here: one to get the address of a new cell, and one to return a cell back to the free list.
• Functions to build a string or a symbol
• Functions to build lists
• A test harness with unit tests

One purpose of this part is only to encode S-expressions into a list or tree representation. Processing of this structures will come later. Another purpose was to check if it was possible to implement all this without stop-and-go garbage collection.

The mechanism used to avoid this is that all cells are at the beginning initialised to belong to a free list. This is a singly linked list with a pointer to the beginning and a pointer to the end of it. Allocation of a cell will always return a cell at the beginning of the list, while deallocation will append the passed cell to the end of the list. The pointers at the beginning and the end will be adjusted accordingly. All other functions build on top of this mechanism. In the development, the usage of unit tests is beneficial. Several defects have been detected through those, even in the later stages of development.

This comes of course at a price. One should make sure that no cyclic structures are created. In a stop-and-go collector it is much easier to clean up such structures.

Another price is that strings use double the space, since each string is composed of a cell with a pointer to the next cell of the string and two characters. Optimising this could be done with a separate pool for strings, but that would double the work needed. Now there is only one mechanism which can be used for everything.

The next part to code will then be the S-expression encoder and decoder. It should not only be possible to encode an expression like

(loop
    for i in (quote (1 2 3 4 5 6 7 8 9 10))
    do (print i))

But also to print an S-expression based upon the internal list structure.

Goal of this journal

While having kept another journal for some time, about problems and solutions, it is probably time to start a journal more specific about the implementation of SSIM-2.

At this point in time, I do have the following available :

- Simulation of certain simple system consisiting of :
- a 32-bit ISA
- A keyboard
- An output device
- A simple system front-end
- An assembler
- A basic software architecture consisting of
- A simple raw memory allocation and control layer
- A definition of basic data types
- Some higher level object factory and garbage collection
interface

What I will be starting on is the implementation of this library using assembler and the call conventions which should be generated by default from the compiler in the future.

The problem is a little bit the same as with Linux. Development consists of a binary image which can be loaded into memory and which takes over the complete system. Before it is finished there will probably be some changes along the way in the assembler, because it should be possible to add these predefined functions as parts of the Lisp symbol table (packages or obtable).

In the meantime, I have obtained some more experience with Common Lisp, and one of the things I learnt is that an image can be enhanced by loading the necessary packages and then dumping it. This obviates the problem of always initialising the standard version of Common Lisp used with the necessary packages.

This means that a development image can be set up which contains :

- a 32-bit ISA
- A keyboard
- An output device
- A simple system front-end
- An assembler

and that these can be accessed and used at will, while always returning to the CL REPL when finished. Ah, well, one problem remains, that is raw input and output must be enabled externally, and if this is done, then normal input is not available.

Currently the main purpose would be to read and assemble the system definitions, having the possibility to load them into the simulator, run them and have the possibility that the system itself formats and displays its output.

It would also be wise to have a standard procedure to rebuild the image when the definitions of the above building blocks change.

Introduction

This is my attempt at a public blog about a project that I basically started a couple of years ago. Publishing a blog, as far as I know, is like writing. I like to read a good written book, and I like to publish my ideas the same way. So this blog is an attempt to become a better writer, but also an attempt to get people interested in my project : designing and building a computer system and use an adapted Lisp as system language.

The things I currently have built are :

• A 32-bit ISA with 32 registers
• A simulator for the above ISA
• A Lisp like assembler
• Lots of documentation

I am currently busy on a compiler for an s-expression based language, which is to become the system language for the system. This language currently only supports 32-bit variables, no arrays and no structures.

When this compiler can be used to start writing system software which can be run on the simulator, it becomes time to learn FPGA design and buy a board which can accomodate the minimum things needed for implementing a computer system : keyboard, console, memory and storage. Using this, it should be possible to move from the simulator to a real, FPGA based, computer system.

And that describes somewhat the bounds of the project.