Jason Gloudon wrote:
On Tue, Jan 21, 2003 at 12:08:29AM +0100, Leopold Toetsch wrote:Here is a proposal for inter code segment jumps: The assembler (imcc) can recognize when a branch ins goes to a different code segment. For such a branch, imcc generates this opcode seqence: inter_cs if i, ic # or whatever
Why do we need branches to go to different code segments ?
Because of this nasty piece of little code:
t/syn/eval_3.imc:
# #!/usr/bin/perl -w
# my $i= 5;
# LAB:
# $i++;
# eval("goto LAB if ($i==6)");
# print "$i\n";
#
# 7
#####
.sub _test
I1 = 5
$S0 = ".sub _e\nif I1 == 6 goto LAB\nend\n.end\n"
compreg P2, "PIR"
compile P0, P2, $S0
LAB:
inc I1
invoke
print I1
print "\n"
end
.end
... I think the expectation has been that control transfers between segments would have their own op, because separate code segments would generally coincide with subs, closures or at least blocks, that have specific entry points.
The problem is, that the "invoke" calls a different code segment, which eventually branches back.
Parsing the eval code into the same code segment in not possible, we can't expand code segments, or let's say not easily, except (if even possible) with invalidating prederef and JIT code, and restarting. This is IMHO too expensive to go that road.
The proposed "inter_cs" op is such a special op, but suitable for all branches. E.g. "inter_cs ; bsr _somewhere"
I just can tell you from imcc's POV. Everything compiled in one sequence (e.g. all subs of all files) could be one code segment. As soon as you start running the code, and you want to compile again, produced bytecode has to go into a different code segment. Of course, it could be more fine grained, but not less.Maybe Dan could give us a hint about the closure/block/byte code segment relationship.
leo
