2.8 KiB
Slot Language
This is a new layer / approach to create code for the next level, the slot_machine.
In essence the slot_language lets us code the slot_machine.
Problem
The Problem with the current way is that some of the slot_machine instructions are really quite complex. They are really more functions than instructions.
This is especially true for everything around the dynamic call. Dynamic call itself is still ok, but resolve_method is too much. And it even uses method_missing, another instruction that is too much, which in turn should use raise and now we really see the point.
I thought about making those "super" instruction real methods and just calling them, but the calling overhead is just too much, and really it is the wrong tool for the job. Calling implies switching of context, while resolve_method and raise and mm really all operate on the same context.
The Slot Machine
The Slot Machine is a kind of memory based, oo abstraction of the risc machine, that in turn mirrors a cpu relatively closely. The machine "knows" the message in the way a cpu knows its registers. And the oo part means it also knows the parfait object model.
While Ruby/Sol code only ever assumes the type of self, the Slot Machine assumes types of the whole of Parfait. The main instruction after which the machine is named is the SlotLoad, which moves one instance variable to another.
Code for the Machine
Since the Slot and SlotMachine have proven useful abstractions, this introduces the SlotLanguage as a way to create code for the SlotMachine.
The SlotMachine defines no methods on objects and passes no objects. While it has call and return, these are defined in terms of jumps and use, like all Slot instructions, the message.
Syntax (projection)
Since we are not defining methods, there is no separate scope. We create objects that will transform to SlotMachine Instructions in the scope of the current method. In other words they will have access to the compiler and the callable, when transforming to SlotMachine (similar to Sol in that way). This means at compile time we can use the frame type and constants, while we can always assume the Message (and not much else) at runtime.
As the scope is "fixed", we will use the file scope, ie one file defines one instruction/macro, by convention of the same name.
For starters we will use ruby syntax, with these semantics:
- only globals and message (the literal) are valid variable names
- dot will mean pointer traversal, sort of like c (no calling)
- names on right hand of dot must be instance variables of left
- equal will mean assignment in the SlotLoad kind of sense
- some macro mechanism is called for (tbd)
- maybe labels have to be created (sort of like the risc dsl)
The result of a compilation will be a SlotMachine Macro