93 lines
3.8 KiB
HTML
93 lines
3.8 KiB
HTML
---
|
|
layout: crystal
|
|
title: Crystal, a simple and minimal oo machine
|
|
---
|
|
|
|
|
|
<div class="row vspace10">
|
|
<div class="span12 center">
|
|
<h3><span>Crystal layers</span></h3>
|
|
<p>Map pretty much to top level directories.</p>
|
|
</div>
|
|
</div>
|
|
<div class="row vspace20">
|
|
<div class="span11">
|
|
<h5>Machine Code, bare metal</h5>
|
|
<p>
|
|
This is the code in arm directory. It creates binary code according to the arm specs. All about shifting bits in the
|
|
right way.
|
|
<br/>
|
|
As an abstraction it is not far away from assembler. I mapped the memnonics to function calls and the registers
|
|
can be symbols or Values (from vm). But on the whole this is as low level as it gets.
|
|
<br/>
|
|
Different types of instructions are implemented by different classes. To make machine dependant code possible,
|
|
those classes are derived from Vm versions.
|
|
<br/>
|
|
There is an intel directory which contains an expanded version of wilson, but it has yet to be made to fit into
|
|
the architecture. So for now crystal produces arm code.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
<div class="row">
|
|
<div class="span12">
|
|
<h5>Parsing, forever descending</h5>
|
|
<p>
|
|
Parsing is relatively straightforward too. We all know ruby, so it's just a matter of getting the rules right.
|
|
<br/>
|
|
If only. Ruby is full of niceties that actually make parsing it quite difficult. But at the moment that story hasn't
|
|
even started.
|
|
<br/>
|
|
Parslet lets us use modules for parts of the parser, so those files are pretty self-explanitory. Not all is done, but
|
|
a good start.
|
|
<br/>
|
|
Parslet also has a seperate Transformation pass, and that creates the AST. Those class names are also
|
|
easy, so you can guess what an IfExpression represents.
|
|
<br/>
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="span12">
|
|
<h5>Virtual Machine</h5>
|
|
<p>
|
|
The Virtual machine layer (vm) is where it gets interesting, but also more fuzzy.
|
|
<br/>
|
|
Currently still quite simple, we have Classes for things we know, like program and function. Also things we need
|
|
to create the code, like Blocks and Instructions.
|
|
<br/>
|
|
The most interesting thing is maybe the idea of a Value. If you think of Variables, Values are what a variable may
|
|
be assigned, but it may carry a storage place (register). Values are constant, and so to
|
|
change a value, we have to create a new Value (of possibly different basic type). Thus
|
|
all machine instructions are the trasformation of values into new ones.
|
|
<br/>
|
|
Also interesting is the slightly unripe Basic Type system. We have a set of machine-word size types and do not
|
|
tag them (like mri or BB), but keep type info seperate. These types include integer (signed/unsigned) object reference
|
|
and function. Most of the oo machine will build on object references. To make that clearer: The (virtual)machine is
|
|
strongly typed (with rtti) and the dynamic ruby behaviour it implemented using that basic type system.
|
|
</p>
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="span12">
|
|
<h5>The flux</h5>
|
|
<p>
|
|
This is just a section of things that are unclear, in flux as it were. This does not included undone things, those
|
|
are plenty too.
|
|
<ul>
|
|
<li> the whole type system, more of values, for object types its quite clear</li>
|
|
<li> booting. There is this Dichotomy of writing code, and figuring out what it should do when it executes,
|
|
that works ok, until i try to think of both, like for booting. </li>
|
|
<li> the oo machine abstraction. Currently non-existant i feel like there is a whole layer missing. Possibly
|
|
with it's own intruction set</li>
|
|
<li> where the core ends, parfait starts and what can be external. </li>
|
|
</ul>
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|