Looking for a Parrot contact person
Gopal V
We've been thinking long and hard about Parrot and found that
the spec viz packfile versions , code segmentations, opcodes and
virtually everything is changing minute to minute ...
So we think it might do good to have a Parrot-dev'r do the
co-ordination duties . What I had in mind was a guy who said to us
"hey folks, the packfile has changed .. refer pod" whenever some
serious change happened. As well as review the opcodes needed for
C# like some sort of i2f or something and report an RFC for that..
I would like to know if anyone would like to ensure that the
two projects remain in constant communication about standards,
specs and stuff...
Also to finish up with a question, how is the perl6 compiler
built ?. A brief look at Tree.pm left me wondering ... it looks
almost like a manual version of treecc code ,with all the sub's
representing operations::names...(just comparing to cscc design,
so that we can keep track of changes to both easily....).
Cheers,
Gopal
--
The difference between insanity and genius is measured by success
Leopold Toetsch
> Hi All,
> We've been thinking long and hard about Parrot and found that
> the spec viz packfile versions , code segmentations, opcodes and
> virtually everything is changing minute to minute ...
No specs are changing currently, but there is some discussion, how to
continue, how to go on - yes. Opcodes are evolving on demand but changes
are - with very limited exceptions - upwards compatible.
The changes are 99.9% internal - all (parrot + perl6) tests are running
during these changes.
This is of course my POV, parrot tree wise.
> So we think it might do good to have a Parrot-dev'r do the
> co-ordination duties . What I had in mind was a guy who said to us
> "hey folks, the packfile has changed .. refer pod" whenever some
> serious change happened.
The problem seems to be, that we (I) don't know, what changes do
actually break e.g. C#, but are totally ok for us, because they are
termed "internal".
I didn't have a look at C# or other projects which might use parrot till
now but if downloading/compiling is cheap (payed ISDN-line related) and
there is a test suite, I can include these tests prior to committing non
bugfixe like changes.
> ... As well as review the opcodes needed for
> C# like some sort of i2f or something and report an RFC for that..
I think Dan is the coordinator here. Though if you can spec your needs
towards opcodes or other issues, more people could consider, how to
efficiently implement these.
> I would like to know if anyone would like to ensure that the
> two projects remain in constant communication about standards,
> specs and stuff...
As _currently_ I seem to be the one, doing ~80% changes in CVS, I
probably should take that part - though I really don't know the demands
of your project. I did read the chat summary. I know there should be
some more non-PMC scalar data types, you need more packfile sections -
but that's currently almost all I know.
So, IMHO a list of features, you'll need for your current dev paths
would be fine. We could coordinate e.g. perl6 feature wishes and C#
demands and lay out next major steps, that will be implemented.
This is a good thing IMHO, because parrot will work for different HLs in
an optimized way.
As you seem to use imcc now as the target assemble language, any
thoughts towards this are welcome too.
> Also to finish up with a question, how is the perl6 compiler
> built ?. A brief look at Tree.pm left me wondering ... it looks
> almost like a manual version of treecc code ,with all the sub's
> representing operations::names...(just comparing to cscc design,
> so that we can keep track of changes to both easily....).
I did download treecc and I had a brief look at it. Yes - it looks like
this is the tool perl6 might need, for going to be native C compiled.
Current thoughts AFAIK are towards a self bootstrapping miniparrot,
compiling the perl written perl6 compiler - but as said AFAIK and far
future still ... print eval(all(@future_dev_paths)) ~ NL;
> Cheers,
> Gopal
leo
Gopal V
> The changes are 99.9% internal - all (parrot + perl6) tests are running
> during these changes.
Hmm... a .pbc I assembled last week refused to run today ... which was
really surprising for me ..
`PackFile_unpack: Bytecode not valid for this interpreter: version mismatch'
So what I had been wondering was , while using a statically typed
language like C# , you need to lookup the method signatures and similar
things at compiletime ... In general, the libs-metadat can be read to
provide this info , but if such changes as above quoted occur ... we
might be into a bumpy road ..
/me wants to be able to cscc -mpvm -lSystem 1.cs for pnet, which would
mean that we need an image loader for parrot as well .. I hope I make
myself clear.
> what changes do actually break e.g. C#, but are totally ok for us,
> because they are termed "internal".
Hmm.... I know pm_nodes.tc is in CVS , but the design issue of classes
is still holding rhys back (or I think so)... So I also don't really know
the breaking points we might have ..
> I can include these tests prior to committing non bugfixe like changes.
Well not today or tomorrow ... Pnet has a nice testsuite (cscctest) to
test the compiler ... And pnet cvs might not be that much a hassle to
compile & test ... So this is almost exactly what I had in mind...
But remember, we still have to hammer out the PMCodeGen nodes to let
you test the stuff ... :-)
> I think Dan is the coordinator here. Though if you can spec your needs
> towards opcodes or other issues, more people could consider, how to
> efficiently implement these.
/me knows Dan is the Designer .... and we might be able to reuse or
slightly readjust the existing opcodes ... That would mean that either
we study parrot from end to end or we ask someone with experience for
advice ... (guess which I'll prefer :-)
> As _currently_ I seem to be the one, doing ~80% changes in CVS, I
> probably should take that part - though I really don't know the demands
> of your project.
Ok, so that would mean the you and rhys should be the people on top...
I think that needs the hands of the two designers and the code demons..
(/me is an implementor , not a designer .... )
> This is a good thing IMHO, because parrot will work for different HLs in
> an optimized way.
Yes ... from a quick glance my expr_compiler code which generates imcc
and il code from arithmetic expressions showed that parrot was quite
faster than pnet (which is unsurprising as pnet is a souped up interpreter).
> As you seem to use imcc now as the target assemble language, any
> thoughts towards this are welcome too.
Nice language ... It solves the eternal problem of register spills
that plague the standard register based VMs . Than means no more
"no linear scan, graph coloring is better" arguments !! ... That's
one of the reasons we're so eager to do it .. Because we can almost
generate subexpression code without a care for spillovers and let
imcc optimise it later..
Theoretically we need only as much temporary variables as (max_stack_size
* max_var_types) .. with $<type><n> being the stack top and all that ..
> I did download treecc and I had a brief look at it. Yes - it looks like
> this is the tool perl6 might need, for going to be native C compiled.
Hmm... it's going to be native compiled ? ... from my experience , trying
to *read* gcc code is more difficult that writing treecc code ...
> Current thoughts AFAIK are towards a self bootstrapping miniparrot,
> compiling the perl written perl6 compiler - but as said AFAIK and far
> future still ... print eval(all(@future_dev_paths)) ~ NL;
That would mean reuse of the exisiting code ... or maybe you should try
your hand at a perl generator for treecc (has gens for c,c++,java & c#)..
Leopold Toetsch
> If memory serves me right, Leopold Toetsch wrote:
> `PackFile_unpack: Bytecode not valid for this interpreter: version mismatch'
Ah, this one. s. "[perl #18072] [PATCH] fingerprinting the PBC" and an
early thread with the keyowrd "fingerprinting". Also mentioned in the
thread "[perl #18056] ..."
Short summary: changing the core.ops significantly (i.e. non comment changes)
invalidates PBC files. You have to rebuild them with a current assembler/imcc.
> So what I had been wondering was , while using a statically typed
> language like C# , you need to lookup the method signatures and similar
> things at compiletime ... In general, the libs-metadat can be read to
> provide this info , but if such changes as above quoted occur ... we
> might be into a bumpy road ..
When core.ops changes, running the PBC normally fails. E.g. inserting a
new OP somewhere in the middle, renumbers all OPs below that point. You
can think of this like switching from libc5 to libc6 or from gcc 2.x to
gcc 3.x - you have to recompile your executables/libs.
When the number and functionality of opcodes stabilizes this will not
happen any more.
> /me wants to be able to cscc -mpvm -lSystem 1.cs for pnet, which would
> mean that we need an image loader for parrot as well .. I hope I make
> myself clear.
Add a Makefile rule that depends on core.ops, or more exactly on the
fingerprint in fingerprint.c.
>>I can include these tests prior to committing non bugfixe like changes.
> But remember, we still have to hammer out the PMCodeGen nodes to let
> you test the stuff ... :-)
Let me know, when it's finished that far, that I can include the tests.
> /me knows Dan is the Designer .... and we might be able to reuse or
> slightly readjust the existing opcodes ... That would mean that either
> we study parrot from end to end or we ask someone with experience for
> advice ... (guess which I'll prefer :-)
Just ask here. Though looking at t/op shows, how the ops are used.
> Ok, so that would mean the you and rhys should be the people on top...
Don't forget Dan here.
> I think that needs the hands of the two designers and the code demons..
> (/me is an implementor , not a designer .... )
me2 - but a lot of RFCs emerged from my keyboard ...
>>As you seem to use imcc now as the target assemble language, any
>>thoughts towards this are welcome too.
> Nice language ... It solves the eternal problem of register spills
> that plague the standard register based VMs . ...
Yes, register allocation ...
> and let
> imcc optimise it later..
.... and optimizer were the primary goals for imcc. Generating/running
PBC is a bonus, I mainly added to speed up perl6 test suite.
> Hmm... it's going to be native compiled ? ... from my experience , trying
> to *read* gcc code is more difficult that writing treecc code ...
I dunno. Not in the next time for sure. And yes ;-)
> That would mean reuse of the exisiting code ... or maybe you should try
> your hand at a perl generator for treecc (has gens for c,c++,java & c#)..
Sean O'Rourke is the master of perl6/PBC.
> Gopal
leo