Question. It seems to me that the current do-loop:
while(code > x && code < y && *code) { DO_OP }
Is fail-fast and succeed-slow. I know it has a brother:
"while(*code)", but this could lead to seg-faults, especially if we allow
dynamically modified parsers / compilers.
The first method has an even more significant problem though. Namely that
the interpreter can't possibly know how big the code-segment is, since
there is the possibility of dynamic loads of p-code or dynamically
generated "eval-code". This is only an issue if parrot assumes a
late-bound compiler, but I'm under the impression that it's strictly
compatible with perl5 which obviously is.
>From this, an earlier bias I had is further reinforced. Since we don't
know the upper and lower bounds of allowed code, and it would be nice to
avoid seg-faults, I recommend:
while(code) { DO_OP }
This is success-fast, and fail only requires execution of the "end"
op-code. (which only executes once for the whole program). It's redundant
to check for the end-op as with while(code && *code){} and it only hurts
mainline performance (though I know that's not yet an issue).
To maintain strict p-code checking, you'd have to dynamically load the
extents of the code-segment (most likely from the interpreter), as with:
while( code > INTERP->start_code && code < INTERP->end_code ) { DO_OP }
jsr's and ret's might modify start/end extents, and so on. (Again *code is
redundant).
A "premature" optimzation could be to have nested do-loops:
func runops( code, interp ):
while( !interp->f_done ):
_innerrunops( interp->start_code, interp, interp->start_code,
interp->start_code + interp->code_size
/* other run-time constants */ );
CHECK_SYSTEM_STATE // potentially avoids litering CHECK_EVENT op-codes
func _innerrunops( code, interp, start, end /* others */ ):
while( code > start && code < end ) { DO_OP }
This would assume that far-jmp / far-jsr (those based on dynamically
linked code) set interp->code and return zero.
I'm not crazy about it; if nothing else, it requires an extra c-function
call, but it might be necessary when we get to dynamic linkiing anyway to
additionally configure the interpreter state (switching current packages,
etc)
I've only recently gotten into this mail-group, so I've missed any
previous justification for the existing use of while(*code), nor any
direction involving dynamic linking.
-Michael
