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.
|