develooper Front page | perl.perl6.internals | Postings from July 2002


Thread Next
Ashley Winters
July 14, 2002 22:13
Message ID:
I decided my next step should be to take a look at the PDDs so I know what's 
going on. I would expect them to be like a writer's canon for a TV show. I'll 
write my impressions as I go on.

Does PDD still mean 'Perl Design Document', or should it mean 'Parrot ...'? 
The documents seem to all refer to the interpreter.

While I'm thinking about it, where will 'Parrot' leave off and 'Perl6' begin? 
At some point, it will be inappropriate to discuss the Parrot interpreter on 
a Perl6 list, since Perl6 might have JVM/CLR backends, and Parrot might have 
Python/Ruby frontends.

PDD01: Perl Design Documents
Question: PerlIO subsystem? Is it PIO now or something?

A description of what level of I/O handling will be available to language 
implementers would be nifty. I never bothered to read up on what PerlIO did, 

Lots of use of the word 'Perl' everywhere. s:ie /perl/parrot/

PDD02: Common vtable format for all variables

Question: Why is the key param for keyed_int vtable functions a pointer? 
Considering I have to implement all those functions to add a PMC... seems odd 
to be passed a pointer to a value which is guaranteed to be non-NULL.

Is every parameter for every vtable function IN? Err, I just found the add_* 
functions. Answer: no. For a specification like this, perhaps in/out could be 
added to parameters or something? It's loathesome non-C clutter, I know. You 
don't have to put it in, I can live without it. :)

Question: set_string_(native|unicode|other) specifies source or dest format? 
I'd assume the string type is the destination's type. It does coercion from 
the source STRING*'s format to the $1 format, right?

Where's keyed_bignum, anyways? Don't have a heart attack! Just kidding.

I don't see any mention of thunking /(.*)(_keyed.*)/ functions to 

Question: Are thunked _keyed methods provided by default for PMC implementors? 
vtables.pod says there are 'sensible' defaults, but it seems to have been 
written pre-keyed-PMCs.

Overall, very informative and intimidating.

PDD03: Parrot Calling Conventions
Definitely a must-read for every assembly-writing parrot coder!

Question: Prototypes aren't specified in Parrot code? I see no pointer to a 
yet-to-be-written calling-convention-specifiying-prototype PDD.

PDD04: Perl's internal data types
Huh? A bunch of stuff about Perl's IV, UV, NV, and some big* structs. From the 
title, I expected a description of INTVAL, FLOATVAL, BIGINT, BIGNUM, and 
STRING. Instead, I see internal details of big* and string implementation 
which I would guess don't match what's being done. I don't see the point.

Question: What should I have gotten from reading this PDD?

PDD05: Opcode Function specs
It took me a second to realize this was a specification of the *.ops file 
functions. It seems obvious now, but it wasn't explicitly stated.

Question: How does JIT work with this?

Whoa, this document is using IV/NV. Needs updating to INTVAL or something.

Umm... the example is totally inconsistent with what's actually in the opcode 

This PDD doesn't need a rewrite; it needs to be superceded.

PDD06: Parrot Assembly Language
Can't really judge it, but based on age alone I'd guess it's for the best I 
didn't try to remember it. No offense.

PDD07: Conventions and Guidelines for Perl Source Code
Coding standard part works for me. As long as it's specific, you can define 
whatever standard you want as long as it's applied consistently.

Naming convention part is obsolete. Probably needs it's own, new PDD.

PDD08: Indexing Aggregate PMCs
I had to read very closely. I don't know if it will ever be simple to explain.

Question: What's @foo["a";12;$hi] trying to do? That's a streamed iterator 
thingy or something in Perl6, if I recall. I've actually read the 
Apocalypses, and I don't see what kind of machine support is needed for that. 
If keyed ops are really implementing @foo["a"][12][$hi], that would be 
multi-dimensional as stated in the PDD.

I can kinda see how someone implementing a vector class would want to know all 
the dimensions at once, but most classes (like PerlArray & PerlHash, I 
assume) will just dereference the first KEY* and send (if non-null) key->next 
to that element's _keyed vtable function, right?

PDD09: Garbage Collection and Dead Object Detection
This reminds me of the time I implemented a copying GC...

I suppose this is good enough for a PDD. Is there a document on how to 
actually do stuff, though? How to allocate memory, get it hooked up to the 
root set through various mechanisms? Do I need to implement the mark vtable 
entry to attach memory to my PMC? Answers like that.

Question: How do I allocate memory?
Question: How do I make sure my memory gets marked while I need it?

Question: Is the GC really implemented in resources.c? It's a non-obvious 
name, and the top-of-file comment doesn't say so.

Okay, that's all of the PDDs. I learned quite a bit from them, hopefully some 
of it was accurate & useful. :)


Ashley Winters

When you do the community's rewrite, try to remember most of us are idiots.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About