own some section

intro done, details tbd

_layouts/site.html

@@ -40,6 +40,9 @@
           <li class="link4">
 						<a href="/salama/layers.html">Architecture</a>
 					</li>
+          <li class="link6">
+						<a href="/soml/soml.html">Soml(Language)</a>
+					</li>
           <li class="link7">
 						<a href="/arm.html">Arm Resources</a>
 					</li>

_layouts/soml.html

@@ -0,0 +1,26 @@
+---
+layout: site
+---
+
+
+
+
+<div class="row vspace10">
+	<div class="span10">
+		<h2 class="center">{{page.title}}</h2>
+		<div>
+    <p class="center"><span> {{page.sub-title}} </span></p>
+		</div>
+	</div>
+	<div class="span2">
+		<div>
+  		<ul class="nav nav-list">
+				<li><a href="/soml/soml.html"> Soml </a> </li>
+				<li><a href="/soml/syntax.html"> Syntax </a> </li>
+				<li><a href="/soml/parfait.html"> Parfait </a> </li>
+  		</ul>
+		</div>
+	</div>
+</div>
+
+{{content}}

soml/soml.html

@@ -0,0 +1,80 @@
+---
+layout: soml
+title: Salama object machine language
+---
+
+
+<div class="row">
+  <div class="span10">
+    <h4>Top down designed language</h4>
+    <p>
+      Soml is a language that is designed to be compiled into, rather than written, like
+      other languages. It is the base for a higher system,
+      designed for the needs to compile ruby. It is not an endeavour to abstract from a
+      lower level, like other system languages, namely off course c.<br/>
+      Still it is a system language, or an object machine language, so almost as low level a
+      language as possible. Only assembler is really lower, and it could be argued that assembler
+      is not really a language, rather a data format for expressing binary code. <br/>
+    </p>
+  </div>
+</div>
+
+<div class="row">
+  <div class="span10">
+    <h5>Object oriented to the core, including calling convention</h5>
+    <p>
+      Soml is completely object oriented and strongly typed. For types, the classes are used, but
+      the main distinction is between object (references) and integers. This is off course
+      essential as dereferencing integers is what we want to avoid.
+    </p>
+    <p>
+      The object model, ie the basic properties of objects that the system relies on, is quite simple
+      and explained below. It involves a single reference per object. <br/> Also the object memory
+      model is kept quite simple in that objects are always small multiples of the cache size of the
+      hardware machine. We use object encapsulation to build up larger looking objects from these
+      basic blocks.
+    </p>
+    <p>
+      The calling convention is also object oriented, not stack based*. Message objects used to
+      define the data needed for invocation. They carry arguments, a frame and return addresses.
+      In Soml return addresses are pre-calculated and determined by the caller, and yes, there
+      are several. In fact there is one return address per masic type, plus one for exception.
+      A method invocation may thus be made to return to an entirely different location than the
+      caller.
+      *(A stack, as used in c, is not typed and as such a source of problems)
+    </p>
+    <p>
+      There is no non- object based memory in soml. The only global constants are instances of
+      classes that can be accessed by writing the class name in soml source.
+    </p>
+  </div>
+</div>
+
+<div class="row">
+  <div class="span10">
+    <h5>Syntax and runtime</h5>
+    <p>
+      Soml syntax is a mix between ruby and c. I is like ruby in the sense that semicolons and even
+      newlines are not neccessary unless they are. It still uses braces, but that will probably
+      be changed. <br/>
+      But off course it is typed, so in argument or variable definitions the type must be specified
+      like in c. Types are classes, but int may be used for brevity instead of Integer. Return
+      types are also declared, though more for statci analysis. As mentioned any function may return
+      to differernt addresses according to type. The compiler automatically inserts erros for
+      return typesa that are not handled by the caller. <br/>
+      The complete syntax and their translation is discussed <a href="syntax.html"> here </a>
+    </p>
+    <p>
+      As soml is the base for dynamic languages, all compile information is recorded in the runtime.
+      All inforamtion is off course object oriented, ie in the form off objects. This means a class
+      hierachy and this itself is off course part of the runtime. The runtime, Parfait, is kept
+      to a minnimum, currently around 15 classes, described in detail <a href="parfait.html">
+      here </a>. <br/>
+      Historically Parfait has been coded in ruby, as it was first needed in the compiler.
+      This had the additional benefit of providing solid test cases for the functionality.
+      Currently the process is to recode the same functionality in soml, and by the end of that
+      a converter will be written. This will convert the soml code into ruby code, thus removing the
+      duplication.
+    </p>
+  </div>
+</div>