Fix renames sol and slot_machine

This commit is contained in:
Torsten Rüger 2019-10-04 01:22:34 +03:00
parent a34550a61f
commit d5e04bccaf
7 changed files with 34 additions and 36 deletions

View File

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

View File

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

View File

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

View File

@ -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 its 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 its own (abstract) instruction set, and the mapping to arm is quite
straightforward. Since the instruction set is implemented as derived classes, additional

View File

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

View File

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

View File

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