Front page | perl.perl6.internals |
Postings from October 2002
Re: Looking for a Parrot contact person
Thread Previous
From:
Leopold Toetsch
Date:
October 27, 2002 03:49
Subject:
Re: Looking for a Parrot contact person
Message ID:
3DBBC23D.7060709@toetsch.at
Gopal V wrote:
> 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
Thread Previous