wrote the crystal page last and also a contribute page
This commit is contained in:
Torsten Ruger
parent
c8cf9578bd
commit
011bb6dd7c
89
crystal.html
Normal file
89
crystal.html
Normal file
@ -0,0 +1,89 @@
|
|||||||
|
---
|
||||||
|
layout: site
|
||||||
|
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. 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 hings we need
|
||||||
|
to create the code, like Blocks and Instructions.
|
||||||
|
<br/>
|
||||||
|
The most interesting thing is maybe the idea of a Value, which are a bit like Variables, just constant. And so to
|
||||||
|
change value of what we think of as a variable, we 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>
|
||||||
|
|
||||||
24
progress.md
24
progress.md
@ -1,24 +0,0 @@
|
|||||||
Some steps along the way
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
Since i forget easily i will write down some milesstones. Project start was around 10.4.2014
|
|
||||||
|
|
||||||
First Assmbly
|
|
||||||
-------------
|
|
||||||
|
|
||||||
With the help of Mikko, there was start for assembler. Threw the parser, wrote lots of tests. First "hello" executable, written in dsl assembler, after 2 weeks.
|
|
||||||
|
|
||||||
First Parses
|
|
||||||
------------
|
|
||||||
|
|
||||||
With Kaspers great parsing library (parslet) was able to get up to speed relatively quickly. Thought it was impossible, but it's only very tricky. Lots of tests at first, then came a good "harness" for the stages.
|
|
||||||
Parsing simple types, if and while, function definition and call, 2 weeks.
|
|
||||||
|
|
||||||
First Executables
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
Going from the parsed ast to assembly was tricky, unknown territory. Uncertainty about right abstractions (eg, Values vs Variables) together with debugging by reading assembler, which i just learn 4 weeks ago, made it tricky.
|
|
||||||
Still, first executables after 2 weeks, hello, fibo, if,while and recursion after 3 weeks.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user