Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) { + STRING *s = $2->vtable->get_repr(interpreter, $2); + $1 = s; goto NEXT(); }
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the "inline" portion of the change... that didn't make a difference.
op or inline has no effect
I've never investigated how to select another "core"...
$ parrot --help
specifically -j -S -C -g
Here's the results *with* the above change:
[EMAIL PROTECTED]:~/parrot$ parrot test.pir 5 T(5) [EMAIL PROTECTED]:~/parrot$ parrot -j test.pir 5 T(5) [EMAIL PROTECTED]:~/parrot$ parrot -S test.pir 5 T(5) [EMAIL PROTECTED]:~/parrot$ parrot -C test.pir 5 T(5) [EMAIL PROTECTED]:~/parrot$ parrot -g test.pir 5 T(5)
Here's the results *without* the above change:
[EMAIL PROTECTED]:~/parrot$ parrot test.pir 5 [EMAIL PROTECTED]:~/parrot$ parrot -j test.pir 5 [EMAIL PROTECTED]:~/parrot$ parrot -S test.pir 5 T(5) [EMAIL PROTECTED]:~/parrot$ parrot -C test.pir 5 T(5) [EMAIL PROTECTED]:~/parrot$ parrot -g test.pir 5
The symptoms I see are that get_repr returns the correct string, but the appropriate REG_STR does not get updated.
Then there is a problem elsewhere. You can inspect interpreter registers too:
gdb> p *interpreter->ctx.bp
In Parrot_PyClass_get_repr, line 197 is:
temp = Parrot_run_meth_fromc_args(INTERP, repr, SELF, REPR, "P");
Before this line is executed,
(gdb) p interpreter->ctx.bp $1 = (struct parrot_regs_t *) 0x40b6bd88
After the above line is executed:
(gdb) p interpreter->ctx.bp $2 = (struct parrot_regs_t *) 0x40b6bae8
Two questions come to mind:
1) Should this call to run_meth change the context? In this case, repr happens to be a Closure based on some assumptions I made early on in this process that I need to revisit. Arguably, this is a bug, but in the general case, can one always assume that the context does not change?
2) If there is the possibility that the context can change, into which context should the results of get_repr be placed? Splitting the statement in op get_repr as I did above guarantees that the macro will expand using the values *after* the call.
Note: if the context is not supposed to change as a result of runops, perhaps an internal exception should be thrown.
- Sam Ruby
