Message from discussion PIR changes coming
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Fri, 17 Oct 2003 09:50:14 -0400
To: Dan Sugalski <d...@sidhe.org>, leopold Toetsch <l...@toetsch.at>
Subject: [RFC] PIR changes coming
References: <firstname.lastname@example.org> <email@example.com> <Pine.LNX.firstname.lastname@example.org> <200310162307.h9GN7hL00955@thu8.leo.home> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Status: No, hits=-0.2 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.44
X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/
From: mrjoltc...@mindspring.com (Melvin Smith)
PIR next phase plans:
(Note: I'd prefer to stay away from AST discussion here, I'm aware that we
eventually wish to pass AST directly to IMCC, but I'd like to shelve
a different thread)
1. .class, .field and .method directive support
These will have to change the packfile format because we need to create the
class layout and symbol table at assembly time. We can probably do this
designing the Class PMC yet, we'll just have to fake it with a Hash PMC.
I'd rather have code like this:
.method Bar proto
# No body
.nativemethod Baz noproto
$P0 = new Class
$P0[":class"] = "TestClass"
store_global "TestClass", $P0
$P0["i"] = 0
$P0["s"] = 0
$I0 = addr _TestClass__SampleMethod
$P1 = new Sub
$P1 = $I0
$P0["SampleMethod"] = $P1
Now you tell me which you'd rather debug. :)
Implicitly this creates all symbols for the class and at load time the correct
PMCs will be created (Method PMCs for the methods, plain types or PMCs for
the fields) and correct method addresses setup.
This abstracts how we implement classes and objects into the IMCC
compiler so we can change it without too much breakage to the
high level languages.
2. Abstraction of subroutine call and return mechanisms based on
compiler directives. I haven't completely figured out how this will look,
but the general idea is, given the correct directive to .sub or .method,
we should be able to hide all the details of the whole .pcc_call thing.
This is less important than (1) but I think it is warranted. Leo and I
already discussed this and we both think it is a good idea.
Probably rather than .sub and .pcc_sub we combine both into
.sub and provide directives like (proto, nonproto, parrotcall, fastcall)
where parrotcall might be the standard continuation calling convention
and the default for any .sub declared with no convention.
I will most likely start on (1) very soon as I'm to the point with Cola
that I need it and I don't like the hash code I'm currently emitting
directly from the code generator to make classes and objects.
My goal is to abstract enough so that PIR could be retargetted with