diff --git a/app/views/pages/misc/soml.html.haml b/app/views/pages/misc/soml.html.haml index cf7d849..12f2ab9 100644 --- a/app/views/pages/misc/soml.html.haml +++ b/app/views/pages/misc/soml.html.haml @@ -17,7 +17,7 @@ typed an untyped was unclear or i didn't get it to work. The current system works by typing self, but not it's instances. A difficult mix to express in a language. %br -This led me to abandon soml and rewrite the functionality as vool and mom layers. +This led me to abandon soml and rewrite the functionality as sol and SlotMachine layers. But Soml was working, the parser is still about and there are some interesting =link_to "benchmarks" , "soml_benchmarks.html" that came from it and really validated the calling convention. diff --git a/app/views/pages/rubyx/builder.html.haml b/app/views/pages/rubyx/builder.html.haml index 335dac0..e92ad53 100644 --- a/app/views/pages/rubyx/builder.html.haml +++ b/app/views/pages/rubyx/builder.html.haml @@ -11,17 +11,17 @@ challenging. The simple object model helps, and so does the simple risc instruction set, but for a long time i was struggling to create readable code that generates the risc. %p - The main places we find this code is the mom layer, eg in the + The main places we find this code is the SlotMachine layer, eg in the =link_to "calling convention" , "calling.html" and in the Builtin module, generating code that can not be expressed in ruby. %h2 Compiler %p - When the code goes from ruby to vool, or vool to mom, methods on the previous (tree) + When the code goes from ruby to Sol, or Sol to SlotMachine, methods on the previous (tree) structure return the next structure. But going to risc the code evolved to use a different approach. The unit of compilation is a block or method, and the respective %b Compiler - is passed into the generating method. + is passed into the generating ruby method. %p The risc code is then added directly to the compiler. If anything is returned it is used by the caller for other things. This change happened as the compiler needed to diff --git a/app/views/pages/rubyx/debugger.html.haml b/app/views/pages/rubyx/debugger.html.haml index 8a47dda..0708982 100644 --- a/app/views/pages/rubyx/debugger.html.haml +++ b/app/views/pages/rubyx/debugger.html.haml @@ -12,7 +12,7 @@ jumping and testing. %p But since it is so simple, it it a little challenging to understand what is happening - in terms of ruby language constructs, or even the Mom abstraction. + in terms of ruby language constructs, or even the SlotMachine abstraction. %p Many test use the Interpreter to test conversion output also dynamically. But to test diff --git a/app/views/pages/rubyx/layers.html.haml b/app/views/pages/rubyx/layers.html.haml index 5d10650..26e18bb 100644 --- a/app/views/pages/rubyx/layers.html.haml +++ b/app/views/pages/rubyx/layers.html.haml @@ -33,22 +33,19 @@ that basically models the ast in a concrete syntax tree. This means there is one class per node type. %p - The Ruby layer is then used to transform the data into the Vool layer. Eg: Implicit + The Ruby layer is then used to transform the data into the Sol layer. Eg: Implicit block passing is made explicit, conditions are simplified, arguments are simplified, and syntactic sugar is removed. -%h3#virtual-object-oriented-language Virtual Object Oriented Language +%h3#simple-object-language Simple Object Language %p - Virtual, in this context, means that there is no syntax for this language; it is an - intermediate representation which - %em could - be targeted by several real languages. + Simpe, in this context, means that it is much simpler than ruby. %p The main purpose is to simplify existing oo languages down to it’s core components: mostly calling, assignment, continuations and exceptions. Typed classes for each language - construct exist and are responsible to transform a statement into Mom level below. + construct exist and are responsible to transform a statement into SlotMachine level below. %p - Examples for things that exist in ruby but are broken down in Vool are + Examples for things that exist in ruby but are broken down in Sol are %em unless , %em ternary operator @@ -58,27 +55,28 @@ %em for loops and other similar syntactic sugar. -%h3#minimal-object-machine Minimal Object machine +%h3#slot-machine SlotMachine %p - We compile Vool statements into Mom instructions. Mom is a machine, which means it has - instructions. But unlike a cpu (or the risc layer below) it does not have memory, only - objects. + We compile Sol statements into SlotMachine instructions. SlotMachine is a machine, + which means it has instructions. But unlike a cpu (or the risc layer below) it does not + have memory, only objects. It also has no registers, and together these two things mean that all information is stored in objects. Also the calling convention is object based and uses Frame and Message instances to save state. %p Objects are typed, and are in fact the same objects the language operates on. Just the functionality is expressed through instructions. While source methods are defined on - classes as Vool, when they are compiled to binary, they are made type specific. These - TypedMethods hold the binary and are stored in the Type. + classes as Sol, when they are compiled to binary, they are made type specific. These + CallableMethods hold the binary and are stored in the Type. %p - The Mom level exists to make the transition to Risc easier. It has a very abstract, + The SlotMachine level exists to make the transition to Risc easier. It has a very abstract, high level instruction set, where each single instruction may resolve to many (even - tens of) lower level instructions. But it breaks down Vool's tree into an instruction + tens of) lower level instructions. But it breaks down Sol's tree into an instruction list, which is conceptually a much easier input for the next layer. %p - Mom instruction may also be used to extend the systm functionality. This feature is used - in the Builtin layer of functions. These functions are coded at the Mom level, as they + SlotMachine uses a class hierachy to represent instructions, and this fact may be used to + extend the systm functionality. This feature is used in the Builtin layer of functions. + These functions are coded at the SlotMachine level, as they can not be expressed in ruby. Examples include instance variable access, integer ops... %h3#risc Risc @@ -86,9 +84,9 @@ The Register machine layer is a relatively close abstraction of risc hardware, but without the quirks that for example arm has. The Risc machine has registers, indexed addressing, operators, branches and everything - needed to implement Mom. It does not try to abstract every possible machine feature + needed to implement SlotMachine. It does not try to abstract every possible machine feature (like llvm), but rather “objectifies” the general risc view to provide what is needed for - the Mom layer, the next layer up (and actually Builtin functions). + the Slot layer, the next layer up (and actually Builtin functions). %p 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 diff --git a/app/views/pages/rubyx/memory.html.haml b/app/views/pages/rubyx/memory.html.haml index 747a197..6174efc 100644 --- a/app/views/pages/rubyx/memory.html.haml +++ b/app/views/pages/rubyx/memory.html.haml @@ -92,7 +92,7 @@ is an Integer. Then it loads the data from both objects, performs the operation, "allocates" a new Integer object and saves the machine word into it. %p - We can also define Mom Instruction to manipulate data, but as work is done in + We can also define SlotMachine Instruction to manipulate data, but as work is done in methods, the Builtin approach has been sufficient up to now. %p Again one may think this is wasteful, the simplest of Integer operation thus taking diff --git a/app/views/pages/rubyx/method_resolution.html.haml b/app/views/pages/rubyx/method_resolution.html.haml index a38fc33..5e0581d 100644 --- a/app/views/pages/rubyx/method_resolution.html.haml +++ b/app/views/pages/rubyx/method_resolution.html.haml @@ -43,24 +43,24 @@ cache of one, captured by the class =ext_link "CacheEntry" , "https://github.com/ruby-x/rubyx/blob/master/lib/parfait/cache_entry.rb" -%h3 Vool +%h3 Sol %p - Static resolution is done at the Vool level, where the CacheEntry is also created + Static resolution is done at the Sol level, where the CacheEntry is also created and then used as any other constant. Ie there is exactly one CacheEntry for every call site (SendStatement). %p - Vool breaks the resolution into it's logical component steps, ie: + Sol breaks the resolution into it's logical component steps, ie: %ul %li Check the current type against cached type %li Update cached type if needed %li Update cached method if needed %li Call the cached method - Breaking down means that Mom Instructions are emitted to effect the logic above. + Breaking down means that SlotMachine Instructions are emitted to effect the logic above. Most of the logic (like the if that is needed) already exists. But the last two steps require special instructions described below. -%h3 Mom +%h3 SlotMachine %p The method cache update described above is basically an assignment where we assign the resolved method to the cache. But to do that, we need to finally @@ -68,7 +68,7 @@ %p The implementation of the %em ResolveMethod - is quite a bit longer than most other Mom instructions, but basically does: + is quite a bit longer than most other SlotMachine instructions, but basically does: %ul %li Load methods from current (cached) type %li Enter a while loop until we hit nil (goto NOT_FOUND if nil) @@ -78,7 +78,7 @@ %li OK: save method in cache To achieve readable code for this low level assembler programming a DSL is used. The - =ext_link "result", "https://github.com/ruby-x/rubyx/blob/master/lib/mom/instruction/resolve_method.rb#L32" + =ext_link "result", "https://github.com/ruby-x/rubyx/blob/master/lib/slot_machine/instruction/resolve_method.rb#L32" is quite understandable. %p diff --git a/app/views/pages/rubyx/parfait.html.haml b/app/views/pages/rubyx/parfait.html.haml index 57c1141..548d3c7 100644 --- a/app/views/pages/rubyx/parfait.html.haml +++ b/app/views/pages/rubyx/parfait.html.haml @@ -26,11 +26,11 @@ oriented system. %p It may be easiest to understand types by how they are used. When rubyx parses a class, - it creates a Vool::Class, which in turn creates a Parfait::Class. This class carries - the Vool methods, basically the language code for the methods. + it creates a Sol::ClassExpression, which in turn creates a Parfait::Class. This class carries + the Sol methods, basically the language code for the methods. %br At this point a type, representing the object layout as known at the time, is created. - Vool::Methods are compiled to binary (Parfait::Method) according to the type information + Parfait::SolMethod are compiled to binary (Parfait::Callable) according to the type information and stored in the type. %br If the class changes at run-time, ie variables are added or removed, a new type object is