to make smaller binaries with larger integer heaps
also ran some benchmarks to see if it makes a difference
at least the binaries are smaller, calling also faster
Now we are using a statically linked list of messages. This will not work with procs, but that can be solved then.
Previous (wrong) thinking was that because of procs messages have to be allocated for every call. This was too slow, and not neccessary
Just like the args, locals are now inlined into the Message.
Message is off course bigger, but as they are created at compile time, that hardly matters
Some programs did get somewhat smaller, especially with both changes, but not super much
Super is a statement, a send really.
Not an expression (as maybe in c++)
The actual implementation will be a bit tricky, like raise, a bit of stack walking, but not impossible. Still, later
When the lambda is passed as argument, it must be moved. This triggers the generation of a corresponding parfait object (as before, and as for other constants) but now also triggers the code build. The code being the constant as it were
Also some more name fixes from renames
The parser presents the whole call that defines the block as a block. And so does the Ruby layer, as we don't want to do processing in ast.
Just making it clearer, also Vool:: block will have to be renamed
Object is the first (obviously) Parfait object to parse and fully compile to binary.
No tests yet, but almost 500 lines of real world code with 17 methods, not bad
previous commit affected rather many test, as the implicit returns add extra instructions
Also added some explicit returns, so as not to test the return logic too much. return (ie return nl) is a knonwn 3 risc operation.
Parfait was depending on it, ie it created a dependency out of Parfait. But Parfiat needs to be self contained.
Moved 2 methods into parfait object, and resolved single call from text_writer to third.
Same same, just have to remembe to actually execute the condition if it is a send
Having send a possible expression, removes one tmp variable and associated move, for a little extra work.
Next return and assign (rest)
Before, when the type was determined, it was assumed that the method can be resolved. But off course tis is not true, as methods may be defined later in the file.
Two solutions for that. One could (and should) define all methods and only then start to compile. Thus having the type safety.
Or (as now) make a dynamic call and let it fail at runtime.
After having over 600 failing tests at one point, this does feel good.
Even better, most of the risc/interpreter tests where i didn't change anything came gree without changing the tests. ie we have binary compatibility.
