mvollmer / suo-old Goto Github PK

This might at one time be SUO
-----------------------------

Suo is yet another crazy attempt at implementing something Schemish.
This time it's an exercise in resisting the urge at premature
optimization.  The plan was to have no significant trickery until the
system is big enough so that one can meaningfully measure the
influence of certain optimization approaches.

This point has been reached; suo can compile its own compiler and can
now grow bigger and smarter.

The goal right now is to create something similar in spirit to the
early hobbyist computers, like the C64, but with Scheme instead of
basic, and running as a program on Unixy operating systems instead of
directly on dedicated hardware.


The name
--------

The word "suo" is Finnish, and I choose a Finnish word because I
started hacking on this after moving to Helsinki.  "Suo" is the
beginning of "Suomi" (Finland) and literally means "swamp".  Well, it
was short, started with "s" like "Scheme" and seemed appropriate for a
project that likely is not going anywhere fast...


Design notes
------------

Suo will run as a Unix process and implement a traditional 'self
modifying image' environment.  Everything is supposed to happen in the
image; there are no fasl files, for example, and the suo operating
system interface will not offer access to the file system at all.  A
suo session can be suspended to disk and resumed.

Everything starts with the definiton of the run-time type system and
memory management.  First, there will be a simple single-generation
copying GC that manages all memory except a small set of 'registers'.
Later on, a generational copying GC is planned.

- Immediates
  - Fixnums
  - Characters
  - Singletons (#t, #f, (), ...)
  
- Non-immediates
  - pairs
  - records
  - vectors
  - bytevectors
  - code

First violation of the simplicity principle: pairs should only take
two words and the tagging can be complicated.

A word is 4 bytes.  All non-immediates start at word boundaries.
Memory above 2 Gigs is not used.  A value is represented as a word.
This word itself tells whether the value is immediate or
non-immediate.  Non-immediates specify their type in the first word of
the memory block pointed to.

Value word:

- xxxxxxxx xxxxxxxx xxxxxxxx xxxxxx00

  Pointer to non-immediate. 

- xxxxxxxx xxxxxxxx xxxxxxxx xxxxxx01

  Fixnum.

- xxxxxxxx xxxxxxxx xxxxxxxx sssss010

  Singletons.  The s-bits describe what it is

  00000: ()
  00001: #t
  00010: #f
  00011: #<unspecified>
  11111: dynamic singleton given in x-bits.
  
- xxxxxxxx xxxxxxxx xxxxxxxx xxxxx110

  Characters (Unicode code points).

- xxxxxxxx xxxxxxxx xxxxxxxx xxxxxx11

  Unusable.

First word of non-immediate block:

- xxxxxxxx xxxxxxxx xxxxxxxx xxxxxx00
  xxxxxxxx xxxxxxxx xxxxxxxx xxxxxx01
  xxxxxxxx xxxxxxxx xxxxxxxx xxxxxx10

  Pair.  The car is the first word itself.

- 0xxxxxxx xxxxxxxx xxxxxxxx xxxxxx11

  Record (fixed length vector).  The first word - b11 points to a
  record descriptor which contains the size as a fixnum in the second
  word.

  'system' records: strings, symbols, floats, complex, bignums,
  ratnums, closures, boxes, etc..

- 1xxxxxxx xxxxxxxx xxxxxxxx xxxx0011

  Vector, x-bits give length in number of words.

- 1xxxxxxx xxxxxxxx xxxxxxxx xxxx1011

  Bytes, x-bits give length in bytes.

- 1xxxxxxx xxxxxxxx xxxxllll llll1111

  Code, x-bits give number of words of instructions, l-bits give
  number of words of literal Scheme values.  Instructions start in
  word 2, followed by the literal values.

The registers will not be machine registers but will be in memory.
There will be 256 general purpose registers and a couple of special
purpose ones.

The GC will initially be a simple copying one with two semi-spaces.

The run-time will be written in C. It can suspend to disk and has
simple IO.  Calls into the runtime will use the C calling convention.

PPC SPECIFICS

The PowerPC has enough registers to use some of them for CPS
registers.  We don't do this right now, tho, because the indirect
approach is simpler and more uniform.  Syscalls are calls to C
functions and we make this easy by staying within the rules of the
PPC32 ABI.

r0 has some funny semantics that I don't understand and thus it is not
used.  (Some instructions treat r0 as constant zero but not all. I
think.)

r1 is the stack pointer and not touched except for syscalls

r2 is reserved by the system and not touched at all

r3, r4 and r5 are volatile and used as temporaries

r14 to r30 are non-volatile and used for the state as follows:

  r14 points to the indirect registers

  r15 points to the current code object

  r16 points to the next free byte

  r17 points just after the last free byte

  r18 - r30 are regular registers used in the generated code