From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 19:43:31 +0200
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
[ a much more detailed answer will follow ]
> ? ?The problem is that inferior runloops cannot be re-entered via
> continuation. ?
C<get_string> is an excellent example for the POC. I've a first question
though: assuming that we might want to eliminate inferior runloops, what can
we do about usage of (e.g.) C<get_string> in:
a) print P0
b) foo(P0) # function call with Preg
...
.sub foo
.param string s # string param
a) could be easy by making the get_string explicit in the opcodes:
$S0 = P0 # imcc could handle this conversion
print $S0
Or print_p (which is not much more complicated than set_s_p) could be
reimplemented using a print_tail_result helper fn instead of
store_tail_result_into_register. (Given the difficulty I've had with
set_retval, that would have made an easier POC, come to think of it.)
but I see little chance to catch b) at compile time. And b) is of
course really nasty, as the C<get_string> is occuring during argument
passing, which has also to be used for any replacement functionality.
leo
Yes, this is a good example of the kind of pain I meant. If we insisted
on trying to optimize this away, we'd be limited to supporting languages
no more dynamic than Java or C# -- and that's pretty limited. ;-} [1]
It can still be done, IIUC. Since an arbitrary number of
get_{string,number,integer} calls might be required, the arg processing
loop would have to be rewritten as a tail-recursion, and then broken
into thunks so that each could be called as a C_continuation if
necessary. But it may depend on how many places need to call
parrot_pass_args and its kin, and how difficult *those* are to rewrite.
This may not be quite so as bad as it seems -- the current algorithm
(as you well know!) already revolves around an explicit struct
call_state. On the other hand, it's not a PMC, and we'd have to figure
out how to keep GC on during arg processing.
Then there are :flat arrays. What if some user passes a :flat arg
using an array class with an overloaded get_pmc_keyed_int method?
Methinks it would be good to draw a line here.
Your detailed reply is eagerly awaited,
-- Bob
[1] Actually, I take that back: For INS formals, IMCC could generate a
prolog that is equivalent to this for each parameter <n>:
C<n>:
unless param_<n>_needs_conversion goto C<n+1>
param_<n> = param_<n>_temp
C<n+1>:
. . .
So if the value destined for param_<n> is a PMC, process_args
stuffs it into param_<n>_temp (still a P register) and sets the
param_<n>_needs_conversion flag. The fact that coercion is
out-of-order with respect to the assignment of other formals should
not matter; it won't be visible to vtable methods [2]. The whole
prolog would be unecessary if all were P formals, and could be
skipped at runtime if no coercion was required.
It rather seems like a band-aid to me. But it would be easier in
the short term.
[2] Unless we should someday provide a mechanism for formals to be bound
dynamically.
