91 lines
4.5 KiB
Plaintext
91 lines
4.5 KiB
Plaintext
%p Going on holiday without a computer was great. Forcing me to recap and write things down on paper.
|
||
%h2#layers Layers
|
||
%p
|
||
One of the main results was that the current layers are a bit mixed up and that will have to be
|
||
fixed. But first, some of the properties in which i think of the different layers.
|
||
%h3#layer-properties Layer properties
|
||
%p
|
||
%strong Structure of the representation
|
||
is one of the main distinction of the layers. We know the parser gives us a
|
||
%strong tree
|
||
and that the produced binary is a
|
||
= succeed "," do
|
||
%strong blob
|
||
%p
|
||
A closely related property of the representation is whether it is
|
||
= succeed "." do
|
||
%strong abstract or concrete
|
||
%p
|
||
If we think of the layer as a language, what
|
||
%strong Language level
|
||
would it be, assembler, c, oo.
|
||
Does it have
|
||
= succeed "," do
|
||
%strong control structures
|
||
= succeed "." do
|
||
%strong jumps
|
||
%h3#ruby-layer Ruby Layer
|
||
%p
|
||
The top ruby layer is a given, since it is provided by the external gem
|
||
= succeed "." do
|
||
%em parser
|
||
= succeed "." do
|
||
%em tree
|
||
%p
|
||
What might sound self-evident that this layer is very close to ruby, this means that inherits
|
||
all of ruby’s quirks, and all the redundancy that makes ruby a nice language. By quirks i mean
|
||
things like the integer 0 being true in an if statement. A good example of redundancy is the
|
||
existence of if and until, or the ability to add if after the statement.
|
||
%h3#virtual-language Virtual Language
|
||
%p
|
||
The next layer down, and the first to be defined in ruby-x, is the virtual language layer.
|
||
By language i mean object oriented language, and by virtual an non existent minimal version of an
|
||
object oriented language. This is like ruby, but without the quirks or redundancy. This is
|
||
meant to be compatible with other oo languages, meaning that it should be possible to transform
|
||
a python or smalltalk program into this layer.
|
||
%p
|
||
The layer is represented as a concrete tree and derived from the ast by removing:
|
||
\- unless, the ternary operator and post conditionals
|
||
\- splats and multi-assignment
|
||
\- implicit block passing
|
||
\- case statement
|
||
\- global variables
|
||
%p It should be relatively obvious how these can be replaced by existing constructs (details in code)
|
||
%h3#virtual-object-machine Virtual object Machine
|
||
%p
|
||
The next down represents what we think of as a machine, more than a language, and an object
|
||
oriented at that.
|
||
%p
|
||
A differentiating factor is that a machine has no control structures like a language. Only jumps.
|
||
The logical structure is more a stream or array. Something closer to the memory that
|
||
i will map to in lower layers. We still use a tree representation for this level, but with the
|
||
interpretation that neighboring children get implicitly jumped to.
|
||
%p
|
||
The machine deals in objects, not in memory as a von Neumann machine would. The machine has
|
||
instructions to move data from one object to another. There are no registers, just objects.
|
||
Also basic arithmetic and testing is covered by the instruction set.
|
||
%h3#risc-layer Risc layer
|
||
%p
|
||
This layer is a minimal abstraction of an arm processor. Ie there are eight registers, instructions
|
||
to and from memory and between registers. Basic integer operations work on registers. So does
|
||
testing, and off course there are jumps. While the layer deals in random access memory, it is
|
||
aware and uses the object machines objects.
|
||
%p
|
||
The layer is minimal in the sense that it defines only instructions needed to implement ruby.
|
||
Instructions are defined in a concrete manner, ie one class per Instruction, which make the
|
||
set of Instructions extensible by other gems.
|
||
%p
|
||
The structure is a linked list which is manly interested in three types of Instructions. Namely
|
||
Jumps, jump targets (Labels), and all other. All the other Instructions a linear in the von Neumann
|
||
sense, that the next instruction will be executed implicitly.
|
||
%h3#arm-and-elf-layer Arm and elf Layer
|
||
%p
|
||
The mapping of the risc layer to the arm layer is very straightforward, basically one to one with
|
||
the exception of constant loading (which is quirky on the arm 32 bit due to historical reasons).
|
||
Arm instructions (being instructions of a real cpu), have the ability to assemble themselves into
|
||
binary, which apart from the loading are 4 bytes.
|
||
%p The structure of the Arm instruction is the same as the risc layer, a linked list.
|
||
%p
|
||
There is also code to assemble the objects, and with the instruction stream make a binary elf
|
||
executable. While elf support is minimal, the executable does execute on rasperry pi or qemu.
|