- No external dependencies means a system that defines an object oriented system language - that compiles to assembler. A sort of object version of c, but without using c. + It must be possible to compile higher level, dynamic, object oriented languages into a typed + intermediate representation, in a similar way that c++ is compiled into c (at least used to be). + So ruby compiles to soml which compiles to assembler which compiles to binaries. + No interpretation.
- It must be possible to compile higher level, dynamic, object oriented languages into this - language, in a similar way that c++ is compiled into c (at least used to be). So ruby compiles - to soml which compiles to assembler which compiles to binaries. No interpretation. -
-- Most of the system is defined in a higher level language (ruby) and only a small runtime, - mostly the class sytsem and os acccess, needs to be written in the system language. + Using the compilation method on it's own runtime (and bootstraping with an exising vm), + it is possible to write the whole system in a dynamic oo language (ruby), thus + removing the two language problem (having to choose between nice and fast)
- A first version of the system language is now done.. - The staticaly typed language is called SOML (salama object machine language), has a roughly - ruby-ish syntax while c-ish semantics, and introduces several new concept: + A first version of the lower level intermediate representation is now done. + Currently there is staticaly typed layer is called SOML (salama object machine layers), which + has roughly c-ish semantics, and introduces several new concept:
An abstract risc like register level defines some abstraction from the actual hardware. The - compiler compiles to this level, but a mapping to Arm is provided to produce working binaries. + soml compiler compiles to this level, but a mapping to Arm is provided to produce working binaries.
There is also an interpreter (mostly for testing) and a basic @@ -67,7 +65,7 @@ layout: site The short introduction is under the architecture menu.
- The section on SOML gives an overview of the system language. + The section on SOML gives an overview of the system layer.
The full documentation is in form of a gitbook and can be viewed here. diff --git a/project/history.html b/project/history.html index 921fb4e..f111f3e 100644 --- a/project/history.html +++ b/project/history.html @@ -113,7 +113,7 @@ title: Salama, where it started
Metasm finally confirmed what i had suspected for a while. - Namely that you don't need C to generate machine code. Metasm has be been assmbling, deassembling and + Namely that you don't need C to generate machine code. Metasm has be been assembling, deassembling and compiling for several cpu's since 2007, in 100% ruby. A great feat, and the only reason i don't use it is because it is too big (for me to understand).
diff --git a/project/motivation.html b/project/motivation.html index e18d30e..9f393d0 100755 --- a/project/motivation.html +++ b/project/motivation.html @@ -74,7 +74,7 @@ sub-title: Salama hopes make the the mysterious more accessible, shed light in t So it is hard to even think of ruby holding us back, and it isn't off course, only current implementations of it are.- So concretely what does this mean: Well i don't know do i! That's the whole point, that anyone can improve it beyond + Concretely what does this mean: Well i don't know do i! That's the whole point, that anyone can improve it beyond the original creators horizon.
diff --git a/salama/layers.html b/salama/layers.html index c0eae13..0765288 100644 --- a/salama/layers.html +++ b/salama/layers.html @@ -142,10 +142,10 @@ title: Salama architectural layers
The idea (because it hasn't been implemented yet) is to have different functions for different - types. The soml layer defines object layout and types and also lets us return to different + types. The soml layer defines the Type class and BasicTypes and also lets us return to different places from a function (in effect a soml function call is like an if). By using this, we can - 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 + compile a single ruby method into several soml functtions. Each such function is typed, ie all + arguments and variables are of known type. According to these types we can call functions 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.
diff --git a/soml/soml.md b/soml/soml.md index 3fbfcde..ee403fe 100644 --- a/soml/soml.md +++ b/soml/soml.md @@ -3,12 +3,19 @@ layout: soml title: Salama object machine language --- +### Disclaimer + +The som Language was a stepping stone: it will go. The basic idea is good and will stay, but the +parser, and thus it's existence as a standalone language, will go. + +What will remain is traditionally called an intermediate representation. Basically the layer into +which the soml compiler compiles to. As such these documents will be rewritten soon. #### 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 +designed for the needs to compile ruby. It is not an endeavor 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