On Mon, 3 Sep 2001, Dan Sugalski wrote:
> Basically chunks of perl code can define opcodes on the fly--they might be
> perl subs that meet the proper critera, or opcode functions defined by C
> code with magic stuck in the parser, or wacky optimizer extensions or
> whatever. There won't be a single global table of these, since we can
> potentially be loading in precompiled code. (Modules, say) Each
> "compilation unit" has its own table of opcode number->function maps.
>
> If you want to think of it C-ishly, each object module would have its own
> opcode table.
Ok, I think I understand. This is some kind of code-compression hack to
avoid using a "call" opcode all over the place, right?
Speaking of soubroutines, what is Parrot's calling conventions? Obviously
we're no long in PUSH/POP land...
> >Or not! Are Perl strings PMCs or not? Why does Parrot want to handle
> >Unicode? Shouldn't that go in a specific language's string PMC vtables?
>
> Strings are a step below PMCs.
I feel like I almost understand this. So when you call the length()
vtable method on a PMC representing a Perl scalar, the length op is
eventually going to call another length() op, this time on an underlying
Parrot string. Right?
I'm still not sure I understand why Parrot is doing string ops at all. Do
all our target languages have identical semantics for string operations?
When you bring Unicode into the mix I start to wonder.
-sam
