At 08:19 PM 9/3/2001 -0400, Sam Tregar wrote:
>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?
No, more a "try and leave the bytecode sections read-only" hack.
Imagine, if you will, building LWP and bytecode compiling it. It uses
private opcodes 1024-1160. Then you later build, say, MIME::Lite, which
uses opcodes 1024-1090. (Since they know nothing of one another there's no
reason they should coordinate their opcode # usage, and whatever case
someone might make for coordinating I can shoot too-large holes in, alas)
If there's only one table, you collide. Or you renumber the opcodes, which
means the module bytecode can't be read-only. Both are icky.
>Speaking of soubroutines, what is Parrot's calling conventions? Obviously
>we're no long in PUSH/POP land...
Up until now, I didn't know, so consider yourself the first to find out. :)
* Integer, String, and Number registers 0-x are used to pass parameters
when the compiler calls routines.
* PMC registers 0-x are used to pass parameters *if* the sub has a
prototype. If the sub does *not* have a prototype, a list is created and
passed in PMC register 0.
* Subs may have variable number, or unknown number, of PMC parameters.
(Basically Parrot variables) They may *not* take a variable or unknown
number of integer, string, or number parameters.
* Subs may not change prototypes
* Sub prototypes must be known at compile time. (I.e. by the end of the
primary compilation phase, and before mainline run time. Basically the
equivalent to the end of BEGIN or beginning of CHECK phase)
* Methods get their parameters passed in as a list in PMC register 0,
unless we can unambiguously figure out their prototype at compilation time
* The callee is responsible for saving any registers he/she/it messes with
* If the return is a list, it goes into PMC register 0. If the return is
prototyped it uses the same rules as for calling.
Don't consider this list final until I've had a chance to run it past
Larry. He might be thinking of allowing prototypes to change, or spring
into existance relatively late in the game. (In which case we probably get
a call_in_list and call_in_registers form of sub call)
> > >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?
Right. Not an op, really, just the length function in the string's table of
functions.
>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.
All our target languages don't have identical semantics, hence the
abstraction. Generally speaking there are a few things that can be
abstracted (comparison and casing, say), and a lot where the details of the
string data is mostly irrelevant (regex matching is pretty much string
neutral--a character is a character, and all it needs is the info on how
big each character is).
We aren't going to have a perfect interface. That much I'm positive of.
(This is engineering--there is no perfection. You weigh the costs and
tradeoffs, and get the mix that works as best you can for your target
problem) We will have a reasonably OK one, though, and one that'll deal
with string data as well as, or better than, what we have now.
I could rant about the fun inherent in string encoding, character sets, and
language issues for a while if you like. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
