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 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#).. Gopal -- The difference between insanity and genius is measured by success
