From d855f20d5229407c8179512671452cbccb2ea96c Mon Sep 17 00:00:00 2001 From: Torsten Ruger Date: Mon, 23 Nov 2015 14:45:01 +0200 Subject: [PATCH] html cleanup widths and things --- _layouts/arm.html | 14 ++-- _layouts/light.html | 25 ------- _layouts/project.html | 3 - _layouts/site.html | 4 +- _layouts/soml.html | 9 +-- arm.md => arm/overview.md | 0 salama/layers.html | 22 ++---- soml/layers.html | 154 -------------------------------------- soml/soml.html | 80 -------------------- soml/soml.md | 62 +++++++++++++++ 10 files changed, 79 insertions(+), 294 deletions(-) delete mode 100644 _layouts/light.html rename arm.md => arm/overview.md (100%) delete mode 100644 soml/layers.html delete mode 100644 soml/soml.html create mode 100644 soml/soml.md diff --git a/_layouts/arm.html b/_layouts/arm.html index 081974c..a3c2c42 100644 --- a/_layouts/arm.html +++ b/_layouts/arm.html @@ -2,26 +2,24 @@ layout: site --- - - -

{{page.title}}

-

{{page.sub-title}}

+ {{content}}
+

More Detail

- -{{content}} diff --git a/_layouts/light.html b/_layouts/light.html deleted file mode 100644 index 1a5e5b2..0000000 --- a/_layouts/light.html +++ /dev/null @@ -1,25 +0,0 @@ - - - - - - - - - - - - - - - - -
-
- {{content}} -
-
- - - - \ No newline at end of file diff --git a/_layouts/project.html b/_layouts/project.html index 8712b71..68846fa 100644 --- a/_layouts/project.html +++ b/_layouts/project.html @@ -2,9 +2,6 @@ layout: site --- - - -

{{page.title}}

diff --git a/_layouts/site.html b/_layouts/site.html index 493e77e..edfc5eb 100644 --- a/_layouts/site.html +++ b/_layouts/site.html @@ -44,7 +44,7 @@ Soml(Language)
  • - Arm Resources + Arm Resources
  • About @@ -70,7 +70,7 @@
    -

    © Copyright 2014.

    +

    © Copyright Torsten Ruger 2013-5.

    diff --git a/_layouts/soml.html b/_layouts/soml.html index 6746ef7..36b9eb6 100644 --- a/_layouts/soml.html +++ b/_layouts/soml.html @@ -2,17 +2,16 @@ layout: site --- - - -

    {{page.title}}

    +

    {{page.sub-title}}

    -

    {{page.sub-title}}

    + {{content}}
    +

    More Detail

    • Soml
      • @@ -22,5 +21,3 @@ layout: site
    - -{{content}} diff --git a/arm.md b/arm/overview.md similarity index 100% rename from arm.md rename to arm/overview.md diff --git a/salama/layers.html b/salama/layers.html index 7f9ef89..c0eae13 100644 --- a/salama/layers.html +++ b/salama/layers.html @@ -4,8 +4,7 @@ title: Salama architectural layers --- -
    -
    +

    Main Layers

    To implement an object system to execute object oriented languages takes a large system. @@ -32,11 +31,9 @@ title: Salama architectural layers bootstraping code

    • -
    -
    -
    +
    Binary , Arm and Elf

    A physical machine will run binaries containing intructions that the cpu understands. With arm @@ -49,11 +46,9 @@ title: Salama architectural layers register load instruction. It is possible to create very dense code using all the arm special features, but this is not implemented yet.

    -
    -
    -
    +
    Register Machine

    The Register machine layer is a relatively close abstraction of risc hardware, but without the @@ -84,11 +79,9 @@ title: Salama architectural layers tremendously in creating this layer. And the interpreter helps in testing, ie keeping it working in the face of developer change.

    -
    -
    -
    +
    Soml, Salama object machine language

    Soml is probably the larest single part of the system and much more information can be found @@ -121,11 +114,9 @@ title: Salama architectural layers implementations for different types of the arguments (statically matched)

    -
    -
    -
    +
    Salama

    To compile and run ruby, we need to parse and compile ruby code. To compile ruby to soml a clear @@ -156,7 +147,6 @@ title: Salama architectural layers compile a single ruby method into several soml methods. Each such method is typed, ie all arguments and variables are of known type. According to these types we can call methods according to their signatures. Also we can autognerate error methods for unhandled types, and predict - that only a fraction of the possible combinations will actually be needed. + that only a fraction of the possible combinations will actually be needed.

    -
    diff --git a/soml/layers.html b/soml/layers.html deleted file mode 100644 index 28c203d..0000000 --- a/soml/layers.html +++ /dev/null @@ -1,154 +0,0 @@ ---- -layout: salama -title: Salama architectural layers ---- - - -
    -
    -

    Main Layers

    -

    - To implement an object system to execute object oriented languages takes a large system. - The parts or abstraction layers are detailed below.
    - 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.
    - 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)
    - The layers are: -

      -
    • Binary and cpu specific assembler. This includes arm assembly and elf support - to produce a binary that can then read in ruby programs
      • -
    • Risc register machine abstraction provides a level of machine abstraction, but - as the name says, quite a simle one.
      • -
    • Soml, Salama object machine language, which is like our object c. Statically - typed object oriented with object oriented call sematics.
      • -
    • Salama , which is the layer compiling ruby code into soml and includes - bootstraping code
      • -
    -

    -
    -
    - -
    -
    -
    Binary , Arm and Elf
    -

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

    -
    -
    - -
    -
    -
    Register Machine
    -

    - The Register machine layer is a relatively close abstraction of risc hardware, but without the - quirks. -
    - 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. -
    - 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). -

    -

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

    -

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

    -
    -
    - -
    -
    -
    Soml, Salama object machine language
    -

    - Soml is probably the larest single part of the system and much more information can be found - here . -
    - 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.
    - It is like ruby with out the dynamic aspects, but typed.
    - In broad strokes it consists off: -

      -
    • Parser: Currently a peg parser, though a hand coded one is planned. - The result of which is an AST
      • -
    • Compiler: compiles the ast into a sequence of Register instructions. - and runtime objects (classes, methods etc)
      • -
    • Parfait: Is the runtime, ie the minimal set of objects needed to - create a binary with the required information to be dynamic
      • -
    • Builtin: A very small set of primitives that are impossible to express - in soml (remembering that parfait will be expressed in soml eventually)
      • -
    -

    -
    -
    - -
    -
    -
    Salama
    -

    -

    -

    -
    -
    - -
    - -
    -
    -
    Parfait
    -

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

    -
    -
    - -
    -
    -
    Builtin
    -

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

    -
    -
    diff --git a/soml/soml.html b/soml/soml.html deleted file mode 100644 index 85bcc72..0000000 --- a/soml/soml.html +++ /dev/null @@ -1,80 +0,0 @@ ---- -layout: soml -title: Salama object machine language ---- - - -
    -
    -

    Top down designed language

    -

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

    -
    -
    - -
    -
    -
    Object oriented to the core, including calling convention
    -

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

    -

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

    -

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

    -

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

    -
    -
    - -
    -
    -
    Syntax and runtime
    -

    - 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.
    - 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.
    - The complete syntax and their translation is discussed here -

    -

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

    -
    -
    diff --git a/soml/soml.md b/soml/soml.md new file mode 100644 index 0000000..1a4b75f --- /dev/null +++ b/soml/soml.md @@ -0,0 +1,62 @@ +--- +layout: soml +title: Salama object machine language +--- + + +#### Top down designed language + +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.
    +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.
    + +##### Object oriented to the core, including calling convention + +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. + +The object model, ie the basic properties of objects that the system relies on, is quite simple +and explained in the runtime section. It involves a single reference per object.
    +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. + +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) + +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. + +##### Syntax and runtime + +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.
    +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.
    +The complete syntax and their translation is discussed here + +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 +here .
    +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.