[NTLK] NEWT/0 set-aref bug

[Matej Horvat]

On Tue, 16 Dec 2014 11:01:11 +0100, Simon Bell <simonbell at me.com> wrote:

> I don’t think the bug is in (or around) set-aref. Here is the code
> Newton generates:
>
> [...]
>
> <function, 0 args, #04C4DE21>
>    0: push-constant 0
>    1: push-constant 0
>    2: push 'array
>    3: make-array 2
>    4: set-var 3 [A]
>    5: push-constant nil
>    6: get-var 3 [A]
>    7: push-constant 0
>    8: push-constant 1
>    9: freq-func 3 [setAref/3]
>   10: get-var 3 [A]
>   11: push-constant 1
>   12: push-constant 2
>   15: freq-func 3 [setAref/3]
>   16: push "Hello world!"
>   17: push 'Print
>   18: call 1
>   19: return

What did you use to compile that code? I compiled the same function with  
NTK and it gives me this:

0000: 20      push-constant 0
0001: 20      push-constant 0
0002: 18      push 'Array
0003: 8A      make-array 2
0004: A3      set-var A
0005: 7B      get-var A
0006: 20      push-constant 0
0007: 24      push-constant 1
0008: C3      freq-func set-aref
0009: 00      pop
000A: 7B      get-var A
000B: 24      push-constant 1
000C: 27 0008 push-constant 2
000F: C3      freq-func set-aref
0010: 00      pop
0011: 19      push "Hello world!"
0012: 1A      push 'Print
0013: 29      call 1
0014: 02      return

I am also curious why your disassembly includes a "push-constant nil"  
instruction. Where does that come from?

> setRef leaves the value it set on the stack as it should according to
> the spec.

Yes, but the returned value is not used, which is why NTK generates a pop  
instruction right after it.

> However, the Newton interpreter unwinds the stack on function
> return to leave just the return value on it.

Does it? Maybe it does indeed as a safety measure, but I have never seen  
NTK not generate an appropriate number of pop instructions to ensure that  
by the time a return instruction is executed, the net result of the  
function is one push.

Still, a bigger problem is if you're using set-aref in a loop without  
popping the result, because the stack will quickly go through the roof  
(pun not intended :P).

> (Any exception handlers are also unstacked at this point.)

Again, I don't know, but in my observations NTK has always generated such  
a sequence of instructions that no matter what path the code takes, it  
will execute the appropriate number of pop-handlers instructions before it  
returns.