I might have a clue as to what's going on with the optimization. This is
beginning to look like it's related to the FT_DIRECT_BRANCHES (unconditional
branches) optimization. More digging with the debugger, except now with
Hans-Peter's sample function:
[0] WWW
[1] ws←3↓1⊃⍎')WSID'
[2] → x
[3] x:
[4] marker ← ⊂'⍝','∆∆∆'
Here's the tokens we start out with before the FT_LABEL_LITERAL optimization
(starting at the branch statement on line 2)
[pc 9] TOK_SYMBOL
[pc 10] TOK_R_ARROW
[pc 11] TOK_ENDL
[pc 12] TOK_APL_VALUE_1. (start of line 4)
[pc 13] TOK_APL_F12_COMMA
The FT_LABEL_LITERAL rewrites the tokens as:
[pc 9] TOK_APL_VALUE1. (value 12)
[pc 10] TOK_R_ARROW
[pc 11] TOK_ENDL
[pc 12] TOK_APL_VALUE_1. (start of line 4)
[pc 13] TOK_APL_F12_COMMA
The FT_DIRECT_BRANCHES optimization in optnimize_unconditional replaces pc 9
with the optimization of TOK_GOTO_PC as follows:
[pc 9] TOK_GOTO_PC (pc 12)
[pc 10] TOK_ENDL
[pc 11] TOK_VOID
[pc 12] TOK_APL_VALUE_1 (start of line 4)
[pc 13] TOK_APL_F12_COMMA
optimize_unconditional_branches then calls remove_TOK_VOID to collapse the
tokens (what I interpret to be "removing a No-op").
The resulting token string is collapsed into the following:
[pc 9] TOK_GOTO_PC (pc 12)
[pc 10] TOK_ENDL
[pc 11] TOK_APL_VALUE_1 (new start of line 4)
[pc 12] TOK_APL_F12_COMMA
When execuring, the interpreter is jumping to PC 12 - which inow points to the
middle of line 4, not the beginning. The SYNTAX ERROR message seems to be
pointing to the "," (ravel0 operator in line 4:
SYNTAX ERROR
WWW[4] marker←⊂'⍝','∆∆∆'
^ ^
Whidh would make sense if the interpreter is jumping to PC 12 instead of 11 in
the optimized code.
While in the debugger, I changed the value of the target PC for the TOK_GOTO_PC
to 11 (the correct start of line 4 of the optimized function. No syntax error.
Seems that the optimization has to go back and fix up any hard-coded PCs in
TOK_GOTO_PC tokens.
- paul
> On Feb 12, 2025, at 9:13 AM, Dr. Jürgen Sauermann
> <m...@xn--jrgen-sauermann-zvb.de> wrote:
>
> Hi,
>
> thanks you all for your hints to the problem.
>
> It very much looks like the problem was caused by an optimization.
> I cannot see why it fails, but until then I have completely disabled
> it (even if enabled in Performance.def).
>
> SVN 1836.
>
> Best Regards,
> Jürgen
>
>
