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
