Paolo Bonzini wrote:
Olivier Blanc wrote:
Hi Paolo,
I couldn't find a way to point out where the bug is appearing.
How do you trace it down ?
I modified a little the code (just to make it more similar to my
Smalltalk coding style), and got a "stack height mismatch", which hints
to a bug in the compiler.
In the bytecode optimizer, more precisely. The optimization of
jumps-to-jumps was causing a jump with a small range (<256 bytes) to
become a jump with a large range (>256 bytes), and the optimizer was
truncating the jump.
I fixed this in 43baff3b8586cae9cb505e8d3bc43c7915d4aa28 by more or less
rewriting the bytecode optimizer (_gst_optimize_bytecodes).
Then I noticed a speedup opportunity, because the optimizer was not
generating a few bytecodes that are in the bytecode set. These are
"compound" bytecodes such as this one
101 = bytecode bc101 {
PREFETCH ();
DUP_STACK_TOP ();
POP_JUMP_FALSE (arg);
}
(used in compiling #and: and #or: messages), this one
165 = bytecode bc165 {
PREFETCH ();
NOT_NIL_SPECIAL ();
POP_JUMP_FALSE (arg);
}
(resulting from "a notNil ifTrue: [...]"), and this one
134 = bytecode bc134 {
ADVANCE ();
POP_STACK_TOP ();
JUMP_BACK (arg);
}
(used in compiling #whileTrue: and #whileFalse: messages). Generation
of these bytecodes is now done, after these three commits:
- 9bc2bf594fd75b4bbc02f4a13b421f545d507880 (a bug fix in the printing of
CompiledMethods)
- 18c63d0a2fcb677f176c30dd933366172f81a328 (bugs in the implementation
of the bytecodes that went unnoticed until now)
- 5aa9ebc511af8bd0615d3fb9e10198d145c22098 (actual generation of the
bytecodes in the optimizer)
I applied all four patches to the 3.0 branch too. Should there be
problems, on the branch I might revert the last one or two.
Paolo
_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
