At 09:50 AM 6/8/2002 +0200, Jerome Vouillon wrote: >On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote: > > First, we need to beef up ret, but that's a problem of definition. It > >Why does ret need to be so smart? We can have an opcode that pop >exception handlers (we need it anyway) and a ret that just return. If >this turn out later to be a performance bottleneck, it will always be >possible to optimize this by adding an opcode that performs both.
Because ret needs to do more than pop exception handlers. It needs to know how to restore the state of the caller. If you call a routine that brings its own environment, that environment needs to be restored on ret. Right now all it does is pop the return address from the global interpreter control stack, but continuations, etc. will have their own control stack, so they must restore the caller's before returning. Also if the callee has to return values we have to get those values to the caller somehow. Since we aren't on the caller's stack, we have to transfer return values implicitly. The Java VM does this by popping values off of the local stack, and onto the callee's stack upon return. -Melvin
