[Libjit-developers] [Fwd: Re: finally support]

[Klaus Treichel]

Hi Aleksey,

that sounds plausible.

An other idea came to my mind to be able to handle catch, finally and
filter functions similar.

They should all work like the filter.
Having an optional argument (not needed for finally but filter and catch
need the exception) and returning an optional value (a boolean for
filter).

But this would be a step for 0.2 i think.

Am Sonntag, den 11.11.2007, 03:48 +0600 schrieb Aleksey Demakov:
> Hi Klaus,
> 
> It seems to me that the best way to implement stack-less finally blocks
> is to add 2 new libjit functions similar to the existing
> jit_insn_start_finally()  and jit_insn_return_from_finally().
> 
> The new functions will differ in that they will explicitly use a value that
> represents a return address.
> 
> jit_value_t jit_insn_start_finally_new(jit_function_t func,
> jit_label_t *finally_label)
> 
> - returns the return address value
> 
> int jit_insn_return_from_finally_new(jit_function_t func, jit_value_t value)
> 
> - takes the return address and jumps to it
> 
> The coder will have to take care of getting the value from the first function
> and passing it to the second.
> 
> Initially I thought that I could do it with the old functions. I thought to 
> have
> internally in libjit a compile-time stack (as opposed to the current run-time
> stack) that will remember for nested finally blocks which one is current
> and which return address value to use for the current block code
> generation.
> 
> However I found in the ECMA spec that it is allowed to have more than one
> endfinally instruction in a single finally block. So I cannot maintain the 
> stack
> internally  - I cannot be sure that jit_insn_return_from_finally is the last 
> one
> for the block and cannot on it automatically pop the returrn address value
> from the compile-time stack.
> 
For the problem with finding the end of the finally block maybe one new
function like int jit_insn_end_finally(jit_function_t func, jit_label_t
*finally_label) would do the trick?
the finally label should be the label associated with the current
finally block.


> I think that in the JIT coder it is possible to remember the return address
> value directly in the ILException struct associated with a given finally
> handler. So in the coder there is no need for a compile-time stack and
> it is going to be fairly simple.
> 
> Does it make sense?
> 
> Regards,
> Aleksey

Cheers,
Klaus

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil