66 lines
3.5 KiB
Markdown
66 lines
3.5 KiB
Markdown
---
|
|
layout: soml
|
|
title: Salama object machine language
|
|
---
|
|
|
|
|
|
#### Top down designed language
|
|
|
|
Soml is a language that is designed to be compiled into, rather than written, like
|
|
other languages. It is the base for a higher system,
|
|
designed for the needs to compile ruby. It is not an endeavour to abstract from a
|
|
lower level, like other system languages, namely off course c.
|
|
|
|
Still it is a system language, or an object machine language, so almost as low level a
|
|
language as possible. Only assembler is really lower, and it could be argued that assembler
|
|
is not really a language, rather a data format for expressing binary code.
|
|
|
|
|
|
##### Object oriented to the core, including calling convention
|
|
|
|
Soml is completely object oriented and strongly typed. Types are modelled as classes and carry
|
|
information about instance variable names and their basic type. *Every* object stores a reference
|
|
to it's types, and while types are immutable, the reference may change. The basic types every
|
|
object is made up off, include at least integer and reference (pointer).
|
|
|
|
The object model, ie the basic properties of objects that the system relies on, is quite simple
|
|
and explained in the runtime section. It involves a single reference per object.
|
|
Also the object memory model is kept quite simple in that objects are always small multiples
|
|
of the cache size of the hardware machine.
|
|
We use object encapsulation to build up larger looking objects from these basic blocks.
|
|
|
|
The calling convention is also object oriented, not stack based*. Message objects used to
|
|
define the data needed for invocation. They carry arguments, a frame and return addresses.
|
|
In Soml return addresses are pre-calculated and determined by the caller, and yes, there
|
|
are several. In fact there is one return address per basic type, plus one for exception.
|
|
A method invocation may thus be made to return to an entirely different location than the
|
|
caller.
|
|
\*(A stack, as used in c, is not typed and as such a source of problems)
|
|
|
|
There is no non- object based memory in soml. The only global constants are instances of
|
|
classes that can be accessed by writing the class name in soml source.
|
|
|
|
##### Syntax and runtime
|
|
|
|
Soml syntax is a mix between ruby and c. I is like ruby in the sense that semicolons and even
|
|
newlines are not neccessary unless they are. Soml still uses braces, but that will probably
|
|
be changed.
|
|
|
|
But off course it is typed, so in argument or variable definitions the type must be specified
|
|
like in c. Type names are the class names they represent, but the "int" may be used for brevity
|
|
instead of Integer. Return types are also declared, though more for static analysis. As mentioned a
|
|
function may return to different addresses according to type. The compiler automatically inserts
|
|
errors for return types that are not handled by the caller.
|
|
The complete syntax and their translation is discussed [here](syntax.html)
|
|
|
|
As soml is the base for dynamic languages, all compile information is recorded in the runtime.
|
|
All information is off course object oriented, ie in the form off objects. This means a class
|
|
hierarchy, and this itself is off course part of the runtime. The runtime, Parfait, is kept
|
|
to a minimum, currently around 15 classes, described in detail [here](parfait.html).
|
|
|
|
|
|
Historically Parfait has been coded in ruby, as it was first needed in the compiler.
|
|
This had the additional benefit of providing solid test cases for the functionality.
|
|
Currently the process is to convert the code into soml, using the same compiler used to compile
|
|
ruby.
|