Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #25980

Re: Execution tokens for return stack manipulation

Show all headers | View raw

Andrew Haley wrote:
> You can't tick and execute >R.
> 
> This is implied because of the interpretation semantics of >R:
> 
>  6.1.0580 >R
>          Interpretation semantics for this word are undefined.
> 
> So, >R has only compilation semantics.

I don't think that is conclusive.  It has execution semantics, if you can't 
' and execute it, having exection semantics is the wrong label, don't you 
think?  If you look at 3.4.3.1, you see that there are two ways to get 
execution semantics: Either by compiling code into a word, or by obtaining 
the xt and executing it.  So if something has execution semantics, I would 
conclude that both obtaining the xt and executing it should work.

The ANS TC had already ruled on the question concerning EXIT, and decided 
that you are allowed not to have an xt for EXIT, i.e. through their 
interpretation, you are right - >R is the same case.

However: The interpretation semantics is what the Forth interpreter does 
with a word.  There is an obvious reason why

: int>r ( n -- r:n )  ['] >r execute ;

doesn't make >r work on the interpreter: It is a definition with an 
unbalanced stack effect.  But in terms of what the standard actually 
specifies (TC interpreations non-withstanding), I would think that ['] >R 
EXECUTE is indeed equivalent to >R inside a definition.  The reason why >R 
has no interpretation semantics is that the interpreter quite likely uses 
the return stack, and >R therefore can't work.

To be honest, this is all a mess, needs to be fixed, and in fact, >R does 
quite often not have execution semantics, but only run-time semantics.  In 
bigForth, e.g., >R is immediate, because this is necessary for the shared 
locals and return stack.  Even a non-immediate >R would not work, because 
that one is a macro which just generates the code for >R.  EXECUTE is an 
indirect call, and therefore modifies the return stack, so >R would 
conflict.  It *is* possible to have a working >R with ['] >R EXECUTE in a 
native code system, though (the executed part just needs to first pop the 
return address, then do the >R, and then return to the popped address), but 
this requires a smart COMPILE, or similar.  In bigForth my conclusion was 
certainly "not worth the effort", in Gforth, the effort is less (threaded 
code), and we even decided to have interpretation semantics, but it must be 
balanced within one line.  The reason we can do this is because in Gforth, 
the EXECUTE happens within the main interpreter loop, so the return stack is 
free to use within that loop (within one line).

I think we have agreed that we need to fix the definitions for the various 
semantics to remove known inconsistencies, and to adjust some words' 
definitions.  Especially those with return stack effects, as they all don't 
have full execution semantics, only run-time semantics.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Execution tokens for return stack manipulation Lauri Alanko <la@iki.fi> - 2013-09-23 19:32 +0000
  Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-23 14:59 -0500
    Re: Execution tokens for return stack manipulation Lauri Alanko <la@iki.fi> - 2013-09-23 20:21 +0000
      Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-23 15:53 -0500
    Re: Execution tokens for return stack manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-23 23:27 +0200
      Re: Execution tokens for return stack manipulation "Alex McDonald" <blog@rivadpm.com> - 2013-09-23 23:37 +0100
      Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-24 06:52 -0500
        Re: Execution tokens for return stack manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-24 12:36 +0000
          Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-24 12:10 -0500
            Re: Execution tokens for return stack manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-24 22:22 +0200
        Re: Execution tokens for return stack manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-24 16:14 +0200
          Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-24 12:12 -0500
  Re: Execution tokens for return stack manipulation "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-09-23 18:09 -0400
  Re: Execution tokens for return stack manipulation "Elizabeth D. Rather" <erather@forth.com> - 2013-09-23 12:40 -1000
    Re: Execution tokens for return stack manipulation Lauri Alanko <la@iki.fi> - 2013-09-23 22:43 +0000
      Re: Execution tokens for return stack manipulation Spam@ControlQ.com - 2013-09-24 01:38 -0400

csiph-web