2015-05-04 13:22:22 +02:00
|
|
|
### Compiling
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-05-24 12:42:29 +02:00
|
|
|
The Ast (abstract syntax tree) is created by [salama-reader](https://github.com/salama/salama-reader)
|
|
|
|
gem and the classes defined there
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-05-24 12:42:29 +02:00
|
|
|
The code in this directory compiles the AST to the virtual machine code, and Parfait object structure.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-05-04 13:22:22 +02:00
|
|
|
If this were an interpreter, we would just walk the tree and do what it says.
|
2015-03-25 16:29:39 +01:00
|
|
|
Since it's not things are a little more difficult, especially in time.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
When compiling we deal with two times, compile-time and run-time.
|
|
|
|
All the headache comes from mixing those two up.*
|
2014-07-25 10:48:06 +02:00
|
|
|
|
|
|
|
Similarly, the result of compiling is two-fold: a static and a dynamic part.
|
|
|
|
|
|
|
|
- the static part are objects like the constants, but also defined classes and their methods
|
2015-07-03 19:13:03 +02:00
|
|
|
- the dynamic part is the code, which is stored as streams of instructions in the MethodSource
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-05-04 13:22:22 +02:00
|
|
|
Too make things a little simpler, we create a very high level instruction stream at first and then
|
|
|
|
run transformation and optimization passes on the stream to improve it.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-10-05 23:27:13 +02:00
|
|
|
The compiler has a method for each type for ast, named along on_xxx with xxx as the type
|
2015-05-04 13:22:22 +02:00
|
|
|
|
2015-10-05 23:27:13 +02:00
|
|
|
#### Compiler holds scope
|
|
|
|
|
2015-10-23 13:22:55 +02:00
|
|
|
The Compiler instance can hold arbitrary scope needed during the compilation. Since we compile Soml
|
2015-10-05 23:27:13 +02:00
|
|
|
(a static language) things have become more simple.
|
|
|
|
|
|
|
|
A class statement sets the current @clazz scope , a method definition the @method.
|
|
|
|
If either are not set when needed compile errors will follow. So easy, so nice.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-07-03 19:13:03 +02:00
|
|
|
All code is encoded as a stream of Instructions in the MethodSource.
|
2015-03-25 16:29:39 +01:00
|
|
|
Instructions are stored as a list of Blocks, and Blocks are the smallest unit of code,
|
|
|
|
which is always linear.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
Code is added to the method (using add_code), rather than working with the actual instructions.
|
2015-05-04 13:22:22 +02:00
|
|
|
This is so each compiling method can just do it's bit and be unaware of the larger structure
|
|
|
|
that is being created.
|
2015-07-03 19:13:03 +02:00
|
|
|
The general structure of the instructions is a graph
|
2015-05-04 13:22:22 +02:00
|
|
|
(with if's and whiles and breaks and what), but we build it to have one start and *one* end (return).
|
2014-07-25 10:48:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
#### Messages and frames
|
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
Since the machine is virtual, we have to define it, and since it is oo we define it in objects.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-03-25 16:29:39 +01:00
|
|
|
Also it is important to define how instructions operate, which is is in a physical machine would
|
2015-10-23 13:22:55 +02:00
|
|
|
be by changing the contents of registers or some stack.
|
2015-05-04 13:22:22 +02:00
|
|
|
|
|
|
|
Our machine is not a register machine, but an object machine: it operates directly on objects and
|
2015-10-23 13:22:55 +02:00
|
|
|
also has no separate stack, only objects. There is only one object which is accessible,
|
|
|
|
basically meaning pinned to a register, the Message.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-10-23 13:22:55 +02:00
|
|
|
One can think of the Message as an oo replacement of the stack.
|
2015-05-04 13:22:22 +02:00
|
|
|
|
2015-10-05 23:27:13 +02:00
|
|
|
When a Method needs to make a call, it creates a NewMessage object.
|
|
|
|
Messages contain return addresses (yes, plural) and arguments.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
|
|
|
The important thing here is that Messages and Frames are normal objects.
|
|
|
|
|
2015-10-07 10:32:48 +02:00
|
|
|
### Distinctly future proof
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-10-23 13:22:55 +02:00
|
|
|
Soml is designed to be used as an implementation language for a higher oo language. Some, or
|
2015-10-05 23:27:13 +02:00
|
|
|
even many, features may not make sense on their own. But these features, like several return
|
2015-10-07 10:32:48 +02:00
|
|
|
addresses, are important to implement the higher language.
|
2014-07-25 10:48:06 +02:00
|
|
|
|
2015-10-23 13:22:55 +02:00
|
|
|
In fact, Soml's main purpose is not even to be written. The main purpose is to have a language to
|
2015-10-05 23:27:13 +02:00
|
|
|
compile ruby to. In the same way that the assembler layer in salama is not designed to be written,
|
|
|
|
we just need it to create our layers.
|