Skip to content

Instantly share code, notes, and snippets.

@atrodo
Created October 28, 2010 03:38
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Embed
What would you like to do?
Less magic == More magic
What I learned from trying to implement Lorito, especially things that were underspecified, in as unorganized mess as
possible.
I learned a few things. First, a simple VM is pretty easy. Really, it's a SMOP task. And fun. I had just enough
guidance, especially from allison's 20 opcode email, to make something that resembled usable.
Second, there might have be some assumptions in place that I may not have realized. Parrot is a large beast that has quite
a bit of history. Most of which, I haven't had the introduction to that others might have. To me, Parrot is a CISC VM
that has it's hundreds of instructions defined by PASM/PIR with 4 registers, the last, PMCs, are rather magical and
apparently, C.
One of the premises that I took with me in implementing Lorito so far is "Make something that C could work with". And I
tried to do that. I chose to make PMCs less magic and more blocks of memory. You can set and manipulate these blocks of
memory to do anything you need them to, include safe references to other PMCs and store symbols. But now, I wonder, if the
assumption was that PMCs would be more akin to structs, having a strict definition in its structure that Lorito could parse
and understand. I wonder if with that would be the loss of flexibility.
Another thing I'm sure was never decided on was calling. There was a lot of talk and ideas about only having goto's.
While I can appreciate that, that would also imply that all the code was a flat address space of all the loaded code. That
seems like it would not always be desirable, like once you start thinking about having "eval" involved. So I took the
approach that code is broken up into logical blocks. Goto's allow you to move to any legal location inside the current
block, and call's are used to move between blocks.
The last point I had for the night is method lookup. I have seen a push to combine PMC vmethods and object methods into a
unified method lookup system. I think this is a great idea, but it has never been well defined how it would operate. The
solution I had was a variation on P&W. It is that each PMC has a pointer to a callable lookup PMC and a vtable PMC. The
lookup PMC would be responsible for looking up and returning any method call anyone needs. Where as P&W defined how to
handle chaining and simple inheritance, I've left that completely up to the PMC/object writer. Two things have come to my
mind as well while working on this. There is still a need to have a simple set of vmethods to do basic operations, like
resize a PMC or freeze, or maybe gather RTTI. Methods that all PMCs must have, and would be static across all PMCs. I
haven't fully considered if that is another op, or another kind of lookup. Second, I'm not entirely convinced that I need
the vtable pointer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment