develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About