It's been a long time coming, six months in fact, that I intended to start blogging again. And by again, I mean actually try and do a good job at it. We'll see.
But, with some prodding by cotto, I've decided, hey, why not, let's review atrodo's little Lorito world. One could argue that I should step back and explain what I'm talking about it, and why I'm interested. But I won't, since it'll take too long and I don't expect people that don't know what I'm talking about to be here yet. If you are, sorry.
But, real quick. Parrot is a virtual machine, not unlike the JVM or .Net. It is aimed at more dynamic languages, but I actually have an interest in static languages on Parrot. Lorito is a hand waving term for a group of refactoring the Parrot project is aiming for. I started a Lorito prototype back in July-ish after some very basic guidelines were posted to parrot-dev by allison. Since then, I've been working on it (along with Hordes of Tarshish and isparrotfastyet.com, not to mention $dayjob) in an attempt to reconcile the visions of other parrot developers and my own. I will be saving my current Lorito vision for another post (which is apparently a narrative, huh). But at issue today is the meeting from last Thursday between some of the core parrot. I would have tried to attend, but Portland is no where close to where I live.
There were 10 points in cotto's notes, so I'll hit my highlights. The original notes can be found on a gist I created, and went on to edit with my notes (this is the current version).
Point 1: There is only context.
This is kind of a muddy idea, leaving a few details that I suspect are important, out. But it's one I can get on board with. I will, for the time being, keep an interpreter around, but change it's function and the concept behind it. From now on, the interpreter will be in charge of executing bytecode as well as holding the pointers to the loaded files, symbols and the PMC heaps (which, not implemented in Lorito yet). The context, for all intents and purposes, holds everything else.
The rest, however, worries me. It implies several key things that I'm not sure I'm on board with. First, that the MOP is so tightly integrated with Lorito, that Lorito cannot be used without using the Lorito MOP. Now, maybe that's desirable to some extent, but the idea of Parrot is to allow a large cross section of languages to target it. If I have to use Lorito's MOP, no matter how flexible it sounds, that sounds contrary to these ideals.
The other worry some part is that setting a program counter makes it jump to C. To me, jumping between the boundaries should be well contained and explicit. The C code is it's own context, it does not share it with the VM. There is also, I think, a lot of good security intentions that will make security more difficult down the line. But that's my gut telling me that.
Point 2: Register Count
That's cool. Although, I had already set my limit to 255, since that's what can fit in a byte to keep the opcode length down. But what really concerns me, is the integration of the MOP with the registers. I just don't understand.
Point 3: Alloc as an op
I've already done this. It's my new op. To me, PMCs are blobs of memory, so that way you don't have two ways of doing essential the same thing. Some may argue that a PMC needs structure, but I don't see why that's not true with my method. Then again, I always take the encapsulation method. Outside code should not be able to peel back the veil and inspect my data structure. This actually leads me to considering a seal function on PMCs, so only a particular code segment can do store or load operations on a PMC. But that has some developing to do.
Point 4: ffi
This is important, I must agree. But I also think this might be outside the bounds of Lorito. Personally, and I've gotten some feedback about this position, I think Lorito bytecode should have one way to interact with anything from the outside world. This means Lorito does not interact with nci or ffi directly. Instead, it delegates that complexity to other code. Yes, I know this sounds inefficient, but I have heard whiteknight and chromatic repeat over and over that PCC (Parrot Calling Convention) is slow. Really slow. So I abandoned anything that resembled PCC for two reasons. First, for the above being slow. Second, because I don't have the opcode length to. Instead, all Lorito calls are made by pushing arguments (all of which are PMCs) onto a stack in the context. If it's a Lorito method, it can pop the arguments off. If it's a C function, the C function can pop the arguments off. In the case of nci or ffi, it can be thunk that massages the arguments into C types, and call the actual C function, arguments in tact. The big advantage of this is the simplicity. If you're interacting with Lorito, you can get the arguments easily with a (inlinable) function call. If you're calling nci or ffi, you still have to do your thing. But you would have to do it anyways. So what I've done is made the simple case simple (and in theory, faster) and the complex case possible. The PCC way is overly complex, and is always complex, even for the simple case.
Point 5: int sizes
Haven't thought a lot about this. Honestly, I've been ignoring the issue.
Point 6: Don't fear the REPR
Seems completely possible to me. No matter if the REPR is at the Lorito level, or at a higher level, this seems worthwhile.
Point 7: CPS and Context
Exactly what I do today. Hurray!
Point 8: Awaiting clarification.
Point 9: Pass
(I know it looks like I'm giving up, but really, there's nothing for me to talk about)
Point A: Strings, not Symbols, are PMCs
That sums it up. The S register in my Lorito are symbols. Not Strings. Strings are high level constructs and deserve to be elevated to PMC status. But low level symbols are a highly useful and time saving construct. I've added no functionality to manipulate symbols. They are there to load into registers and compare. That is about all they can do.
Conclusion:
I was hoping for concrete answers from last Thursday, and I got some, but I also got a lot more possible directions. So, I am going to keep on doing what I've been doing, and try and reconcile ideas as the come along and advocating what I've done so far. Not sure where this is going to lead me and Parrot, but the possibilities are interesting to watch unfold.
And wow, that's a lot of text for such a short topic.
No comments:
Post a Comment