Re: nest-sys revisited

On 17/03/2025 11:12 pm, Hans Bezemer wrote:

On 17-03-2025 02:14, dxf wrote:

Would you agree 'nest-sys' are peculiar to colon definitions.  That
EXECUTE is a different class of function.  It's not doing a 'call'
as such and not leaving anything on the 'return stack'?

 
Ok, in order to answer that question, I'll always fall back to the standard:
 
6.1.0070: "When interpreting, ' xyz EXECUTE is *equivalent* to xyz."
 
Alright. In my book, that smells like a CALL. I was doubting for a second where Forth would land after executing EXECUTE. I'd say - after EXECUTE.
 
How did it know it had to land there? Now I know there are some weird methods of achieving that (like patching the return address of the subroutine), but I'm not in the habit of seriously considering these.
 
My code just says:
 
CODE (EXECUTE)  DSIZE (1); a = DPOP; RPUSH ((cell) PROGCOUNT);
                XT (a); JUMP (a); NEXT;
 
It's not that different from:
 
CODE (CALL)     RFREE (1); RPUSH ((cell) PROGCOUNT);
                JUMP (OPERAND); NEXT;
 
(And no, there is not an error there. 4tH has a shared stack, so if there is room on the data stack, and that item is removed, there is now space on the return stack.)
 
In short - why is it not doing "a call"? Because it is not a jump.

My bad.  While EXECUTE might not push a 'nest-sys' onto the return stack,
there seems to be no issue doing so.  E.g. the following works under
SwiftForth (native code, CALLed EXECUTE) irrespective of which definition
of LOCAL was used.

: ;: ( nest-sys -- )  >r ;

\ : LOCAL ( x adr -- )  r> -rot dup @ over 2>r ! ;: 2r> ! ;
 : LOCAL ( x adr -- )  r> -rot dup @ over 2>r ! ['] ;: execute 2r> ! ;

\ Example
variable A  variable B  8 a !  7 b !

: divide ( a b -- )  b local  a local
  a @  b @  /  . cr  ;

15 3 divide  a ? b ?