ruby-x.github.io/soml/layers.html

---
layout: salama
title: Salama architectural layers
---


<div class="row">
  <div class="span10">
    <h4>Main Layers</h4>
    <p>
      To implement an object system to execute object oriented languages takes a large system.
      The parts or abstraction layers are detailed below.</br>
      It is important to undrstand the approach first though, as it differs from the normal
      interpretation. The idea is to compile (eg) ruby. It may be easiest to compare to a static
      object oriented language like c++. When c++ was created c++ code was translated into c, which
      then gets translated into assembler, which gets translated to binary code, which is linked
      and executed. Compiling to binaries is what gives these languages speed, and is one reason
      to compile ruby.       </br>
      In a similar way to the c++ example, we need language between ruby and assembler, as it is too
      big a mental step from ruby to assembler. Off course course one could try to compile to c, but
      since c is not object oriented that would mean dealing with all off c's non oo heritance, like
      linking model, memory model, calling convention etc. (more on this in the book) <br/>
      The layers are:
      <ul>
        <li> <b> Binary and cpu specific assembler.</b>  This includes arm assembly and elf support
              to produce a binary that can then read in ruby programs</li>
        <li> <b> Risc register machine abstraction </b> provides a level of machine abstraction, but
                  as the name says, quite a simle one.</li>
        <li> <b> Soml, Salama object machine language, </b> which is like our object c. Statically
                typed object oriented with object oriented call sematics. </li>
        <li> <b> Salama </b> , which is the layer compiling ruby code into soml and includes
            bootstraping code</li>
      </ul>
    </p>
  </div>
</div>

<div class="row">
  <div class="span10">
    <h5>Binary , Arm and Elf</h5>
    <p>
      A physical machine will run binaries containing intructions that the cpu understands. With arm
      being our main target, this means we need code to produce binary, which is contained in a
      seperate module <a href="https://github.com/salama/salama-arm"> salama-arm </a>. <br/>
      To be able to run code on a unix based operating system, binaries need to be packaged in a
      way that the os understands, so minimal elf support is included in the package. <br/>
      Arm is a risc architecture, but anyone who knows it will attest, with it's own quirks.
      For example any instruction may be executed conditionally in arm. Or there is no 32bit
      register load instruction. It is possible to create very dense code using all the arm
      special features, but this is not implemented yet.
    </p>
  </div>
</div>

<div class="row">
  <div class="span10">
    <h5>Register Machine</h5>
    <p>
      The Register machine layer is a relatively close abstraction of risc hardware, but without the
      quirks.
      <br/>
      The register machine has registers, indexed addressing, operators, branches and everything
      needed for the next layer. It doesn not try to abstract every possible machine leature
      (like llvm), but rather "objectifies" the risc view to provide what is needed for soml, the
      next layer up.
      <br/>
      The machine has it's own (abstract) instruction set, and the mapping to arm is quite
      straightforward. Since the instruction set is implemented as derived classes, additional
      instructions may be defined and used later, as long as translation is provided for them too.
      In other words the instruction set is extensible (unlike cpu instruction sets).
    </p>
    <p>
      Basic object oriented concepts are needed already at this level, to be able to generate a whole
      self contained system. Ie what an object is, a class, a method etc. This minimal runtime is called
      parfait and will be coded in soml eventually. But since it is the same objects at runtime and
      compile time, it will then be translated back to ruby for use at compile time. Currenty there
      are two versions of the code, in ruby and soml, being hand synchronized. More about parfait below.
    </p>
    <p>
      Since working with at this low machine level (essentially assembler) is not easy to follow for
      everyone, an interpreter was created. Later a graphical interface, a kind of
      <a href="https://github.com/salama/salama-debugger"> visual debugger </a> was added.
      Visualizing the control flow and being able to see values updated immediately helped
      tremendously in creating this layer. And the interpreter helps in testing, ie keeping it
      working in the face of developer change.
    </p>
  </div>
</div>

<div class="row">
  <div class="span10">
    <h5>Soml, Salama object machine language</h5>
    <p>
      Soml is probably the larest single part of the system and much more information can be found
      <a href="/soml/soml.html"> here </a>.
      <br/>
      Before soml, a more traditional virtual machine approach was taken and abandoned. The language
      is easy to understand and provides a good abstraction, both in terms of object orienteation,
      and in terms of how this is expressed in the register model. <br/>
      It is like ruby with out the dynamic aspects, but typed. <br/>
      In broad strokes it consists off:
      <ul>
        <li> <b> Parser:</b> Currently a peg parser, though a hand coded one is planned.
                  The result of which is an AST</li>
        <li> <b> Compiler:</b>  compiles the ast into a sequence of Register instructions.
                  and runtime objects (classes, methods etc)</li>
        <li> <b> Parfait: </b> Is the runtime, ie the minimal set of objects needed to
                  create a binary with the required information to be dynamic</li>
        <li> <b> Builtin: </b>  A very small set of primitives that are impossible to express
                  in soml (remembering that parfait will be expressed in soml eventually)</li>
      </ul>
    </p>
  </div>
</div>

<div class="row">
  <div class="span10">
    <h5>Salama</h5>
    <p>
    </p>
  </p>
  </div>
</div>

</div>

<div class="row">
  <div class="span12">
    <h5>Parfait</h5>
    <p>
      Ruby is very dynamic, and so it has a relatively large run-time. Parfait is that Run-time.
      <br/>
      Parfait includes all the functionality a ruby program could not do without, Array, Hash, Object, Class, etc.
      <br/>
      Parfait does not include any stdlib or indeed core functionality if it doesn't have too.
      <br/>
      Parfait is coded in ruby, but not all functionality can be coded in ruby, so there is Builtin
    </p>
  </div>
</div>

<div class="row">
  <div class="span12">
    <h5>Builtin</h5>
    <p>
      Builtin is the part of the vm that can not be coded in ruby. It is not, as may be imagined, a set of instructions,
      but rather a set of modules.
      <br/>
      Modules of Builtin have functions that implement functionality that can not be coded in ruby. Ie array access.
      The functions take a VM::Method and provide the code as a set of instructions. This may be seen as the assembler
      layer if the vm.
    </p>
  </div>
</div>