Dan Sugalski <[EMAIL PROTECTED]> wrote:
Exceptions and continuations should be the same problem -- the target is the start of a basic block. (Well, more than that, as they're places where calling conventions potentially kick in) This means the instruction immediately after a sub call starts a new block, as does the start of an exception handler.
Dan, I've already said that there is of course a new basic block. The problem arises by the silent generation of loops in the CFG. Within a loop the same register can't be reallocated to a different variable. There are two possible solutions (AFAIK):
1) statically mark the branch target of the loop. Proposed syntax constructs:
1a) for exceptions:
Exceptions are going to get redone later. Probably (hopefully) later today.
1b) generally
RESUMABLE: func_that_might_loop_through_cc()
Blech. No. The instruction after a function call's inherently a destination (sort of, given how we're generally guaranteeing register contents), as is any label and the target of a branch operation. (Though most branch operations are going to labels so there's some redundancy)
If the point is to direct the allocator to flush temps and start fresh, then we should just do it:
.flushtemps
or
.fardestination
rather than playing label overloading games.
2) Fetch all from lexicals/globals after a function call.
This should only be necessary for volatile I and N values for normal (i.e. ones where parrot automatically generates the return continuation) function and method calls, since the S and P registers should be fine across the call.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
