Front page | perl.perl6.internals |
Postings from October 2002
Re: Looking for a Parrot contact person
From: Gopal V
October 26, 2002 15:21
Re: Looking for a Parrot contact person
Message ID: 20021027014258.A6326@md3.vsnl.net.in
If memory serves me right, Leopold Toetsch wrote:
> 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
> 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#)..
The difference between insanity and genius is measured by success