Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[forth200x] RfD: Drop execution semantics of LEAVE and UNLOOP
61 views
Skip to first unread message
Bernd Paysan
May 9, 2012, 1:42:13 PM5/9/12
to
Problem: LEAVE and UNLOOP are defined to have no interpretation
semantics, but an execution semantics. This implies that ['] LEAVE
EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
bigForth, and VFX, and this is not the case in any of these systems.
: test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
VFX fails during execution with a meaningful error message:
10 test 0 1 2 3
Err# -14 ERR: Attempt to interpret a compile only definition.
Gforth fails while compiling with a meaningful error message:
:1: Cannot tick compile-only word (try COMP' ... DROP)
: test 0 ?DO i dup . 3 = IF ['] >>>leave<<< execute THEN LOOP ;
bigForth fails silently without a meaningful error message:
10 test 0 1 2 3 4 5 6 7 8 9 ok
Feel free to check more. UNLOOP is defined similarly, and while Gforth
and VFX perform ['] UNLOOP EXECUTE correctly, bigForth doesn't (and it
would not be difficult to "fix" bigForth). However, I consider the
standard to be overspecified here, too. There is no practical reason
why UNLOOP must have execution semantics.
Solution: Remove "Execution:" from the definition of LEAVE and UNLOOP.
Insert instead
Compilation: ( -- )
Append the run-time semantics given below to the current
definition.
Run-Time:
Rationale:
This change is to allow alternative implementations of LEAVE and UNLOOP
with special compilation semantics. Especially for LEAVE, this is
common practice.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
semantics, but an execution semantics. This implies that ['] LEAVE
EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
bigForth, and VFX, and this is not the case in any of these systems.
: test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
VFX fails during execution with a meaningful error message:
10 test 0 1 2 3
Err# -14 ERR: Attempt to interpret a compile only definition.
Gforth fails while compiling with a meaningful error message:
:1: Cannot tick compile-only word (try COMP' ... DROP)
: test 0 ?DO i dup . 3 = IF ['] >>>leave<<< execute THEN LOOP ;
bigForth fails silently without a meaningful error message:
10 test 0 1 2 3 4 5 6 7 8 9 ok
Feel free to check more. UNLOOP is defined similarly, and while Gforth
and VFX perform ['] UNLOOP EXECUTE correctly, bigForth doesn't (and it
would not be difficult to "fix" bigForth). However, I consider the
standard to be overspecified here, too. There is no practical reason
why UNLOOP must have execution semantics.
Solution: Remove "Execution:" from the definition of LEAVE and UNLOOP.
Insert instead
Compilation: ( -- )
Append the run-time semantics given below to the current
definition.
Run-Time:
Rationale:
This change is to allow alternative implementations of LEAVE and UNLOOP
with special compilation semantics. Especially for LEAVE, this is
common practice.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Marcel Hendrix
May 9, 2012, 2:15:29 PM5/9/12
to
Bernd Paysan <bernd....@gmx.de> writes Re: [forth200x] RfD: Drop execution semantics of LEAVE and UNLOOP
[..]
x86_64 binary, native floating-point, extended precision.
Copyright 1996 - 2012 Marcel Hendrix.
FORTH> : test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ; ok
FORTH> 10 test 0 1 2 3
Error -26
No LOOP defined ?
FORTH> : test2 0 ?DO i dup . 3 = IF ['] unloop execute THEN LOOP ; ok
FORTH> 10 test2 0 1 2 3
Error -26
No LOOP defined ?
Strange messages perhaps, but perfectly obvious from the compiler's
viewpoint.
-marcel
[..]
> Problem: LEAVE and UNLOOP are defined to have no interpretation
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
> bigForth, and VFX, and this is not the case in any of these systems.
[..]
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
> bigForth, and VFX, and this is not the case in any of these systems.
> bigForth fails silently without a meaningful error message:
> 10 test 0 1 2 3 4 5 6 7 8 9 ok
> Feel free to check more. UNLOOP is defined similarly, and while Gforth
> and VFX perform ['] UNLOOP EXECUTE correctly, bigForth doesn't
iForth version 4.0.807, generated 21:33:31, February 22, 2012.
> 10 test 0 1 2 3 4 5 6 7 8 9 ok
> Feel free to check more. UNLOOP is defined similarly, and while Gforth
> and VFX perform ['] UNLOOP EXECUTE correctly, bigForth doesn't
x86_64 binary, native floating-point, extended precision.
Copyright 1996 - 2012 Marcel Hendrix.
FORTH> : test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ; ok
FORTH> 10 test 0 1 2 3
Error -26
No LOOP defined ?
FORTH> : test2 0 ?DO i dup . 3 = IF ['] unloop execute THEN LOOP ; ok
FORTH> 10 test2 0 1 2 3
Error -26
No LOOP defined ?
Strange messages perhaps, but perfectly obvious from the compiler's
viewpoint.
-marcel
Alex McDonald
May 9, 2012, 2:22:24 PM5/9/12
to
STC Experimental 32bit: 0.05.01 Build: 544
: test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
10 test 0123
^
Error -14 test is compilation only
It gets the name wrong, but that's due to the information available
after the parse. Interestingly, Win32Forth (an ITC) doesn't fail.
Win32Forth: a 32 Bit Forth for Windows 95/98/ME/NT4/W2K/XP/VISTA and
WIN
Version: 6.14.00 Build: 4
Compiled: Sunday, November 14 2010, 10:30AM
: test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ; ok
10 test 0 1 2 3 ok
Mark Wills
May 9, 2012, 3:17:51 PM5/9/12
to
Krishna Myneni
May 9, 2012, 6:47:19 PM5/9/12
to
On May 9, 12:42 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Problem: LEAVE and UNLOOP are defined to have no interpretation
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
> bigForth, and VFX, and this is not the case in any of these systems.
>
> : test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
>
> VFX fails during execution with a meaningful error message:
> 10 test 0 1 2 3
> Err# -14 ERR: Attempt to interpret a compile only definition.
>
> Gforth fails while compiling with a meaningful error message:
> :1: Cannot tick compile-only word (try COMP' ... DROP)
> : test 0 ?DO i dup . 3 = IF ['] >>>leave<<< execute THEN LOOP ;
>
> bigForth fails silently without a meaningful error message:
> 10 test 0 1 2 3 4 5 6 7 8 9 ok
>
> Feel free to check more. UNLOOP is defined similarly, and while Gforth
> and VFX perform ['] UNLOOP EXECUTE correctly, bigForth doesn't (and it
> would not be difficult to "fix" bigForth). However, I consider the
> standard to be overspecified here, too. There is no practical reason
> why UNLOOP must have execution semantics.
> ...
> Problem: LEAVE and UNLOOP are defined to have no interpretation
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
> bigForth, and VFX, and this is not the case in any of these systems.
>
> : test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
>
> VFX fails during execution with a meaningful error message:
> 10 test 0 1 2 3
> Err# -14 ERR: Attempt to interpret a compile only definition.
>
> Gforth fails while compiling with a meaningful error message:
> :1: Cannot tick compile-only word (try COMP' ... DROP)
> : test 0 ?DO i dup . 3 = IF ['] >>>leave<<< execute THEN LOOP ;
>
> bigForth fails silently without a meaningful error message:
> 10 test 0 1 2 3 4 5 6 7 8 9 ok
>
> Feel free to check more. UNLOOP is defined similarly, and while Gforth
> and VFX perform ['] UNLOOP EXECUTE correctly, bigForth doesn't (and it
> would not be difficult to "fix" bigForth). However, I consider the
> standard to be overspecified here, too. There is no practical reason
> why UNLOOP must have execution semantics.
Another data point, with kForth:
$ kforth
kForth v 1.5.3 (Build: 2012-04-07)
Copyright (c) 1998--2012 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw
Provided under the GNU General Public License.
ok
: test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
ok
10 test
0 1 2 3 Line 2: VM Error(12): No matching DO
10 test
ok
: test2 0 ?DO i dup . 3 = IF ['] unloop execute THEN LOOP ;
ok
10 test2
0 1 2 3 Line 4: VM Error(5): Return stack corrupt
10 test2
Rod Pemberton
May 10, 2012, 4:10:52 AM5/10/12
to
"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:joea9l$vge$1...@online.de...
10 TEST 0 1 2 3 ok
BB4WForth
10 TEST
news:joea9l$vge$1...@online.de...
> Problem: LEAVE and UNLOOP are defined to have no interpretation
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
> bigForth, and VFX, and this is not the case in any of these systems.
>
> : test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
>
> VFX fails during execution with a meaningful error message:
> 10 test 0 1 2 3
> Err# -14 ERR: Attempt to interpret a compile only definition.
>
> Gforth fails while compiling with a meaningful error message:
> :1: Cannot tick compile-only word (try COMP' ... DROP)
> : test 0 ?DO i dup . 3 = IF ['] >>>leave<<< execute THEN LOOP ;
>
> bigForth fails silently without a meaningful error message:
> 10 test 0 1 2 3 4 5 6 7 8 9 ok
>
> Feel free to check more.
Win32Forth
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body. I checked Gforth,
> bigForth, and VFX, and this is not the case in any of these systems.
>
> : test 0 ?DO i dup . 3 = IF ['] leave execute THEN LOOP ;
>
> VFX fails during execution with a meaningful error message:
> 10 test 0 1 2 3
> Err# -14 ERR: Attempt to interpret a compile only definition.
>
> Gforth fails while compiling with a meaningful error message:
> :1: Cannot tick compile-only word (try COMP' ... DROP)
> : test 0 ?DO i dup . 3 = IF ['] >>>leave<<< execute THEN LOOP ;
>
> bigForth fails silently without a meaningful error message:
> 10 test 0 1 2 3 4 5 6 7 8 9 ok
>
> Feel free to check more.
10 TEST 0 1 2 3 ok
BB4WForth
10 TEST
0 1 2 3 ok
RP
The Beez
May 14, 2012, 3:14:08 AM5/14/12
to
On May 10, 12:47 am, Krishna Myneni <krishna.myn...@ccreweb.org>
wrote:
I hasten to say that 4tH still uses a control stack with reference (as
in Forth-79). It's pretty bullet proof as long as you treat it as a
stack, even when resolving complex loops like BEGIN..
WHILE..WHILE..UNTIL. Even DO..LOOP works pretty well, unless you're
trying to resolve a LEAVE. That's why my LEAVE is still Forth-79, that
is: it sets the counter to the limit, job done. UNLOOP is inlined,
"2R> 2DROP". Both cannot be ticked, so this discussion doesn't really
touch me.
I've never been a proponent of all "fixes" concerning DO..LOOP and
your results just confirm this point of view. The idea of somehow
"resolving" LEAVE is flawed at best, because it can be embedded in an
IF..THEN statement (which needs to be resolved first). I found the
same problems when trying to develop my DONE..DONE statement, which
executes when a while has failed. I could not make a BREAK or CONTINUE
easily for that very same reason.
But why are we continuing to try to "fix" something that is so
profoundly flawed? Why can't we make the right decision and fix it
once and for all?
10 0 2 +DO .. LOOP
which compiles to:
swap
>r >r >r
:1 2 rpick rover -
0= if branch :2
..
rover r+
branch :1
2: ...
(Probably some assembly required, but you catch my drift). Where ?DO
equals 1 +DO.
Hans Bezemer
wrote:
I hasten to say that 4tH still uses a control stack with reference (as
in Forth-79). It's pretty bullet proof as long as you treat it as a
stack, even when resolving complex loops like BEGIN..
WHILE..WHILE..UNTIL. Even DO..LOOP works pretty well, unless you're
trying to resolve a LEAVE. That's why my LEAVE is still Forth-79, that
is: it sets the counter to the limit, job done. UNLOOP is inlined,
"2R> 2DROP". Both cannot be ticked, so this discussion doesn't really
touch me.
I've never been a proponent of all "fixes" concerning DO..LOOP and
your results just confirm this point of view. The idea of somehow
"resolving" LEAVE is flawed at best, because it can be embedded in an
IF..THEN statement (which needs to be resolved first). I found the
same problems when trying to develop my DONE..DONE statement, which
executes when a while has failed. I could not make a BREAK or CONTINUE
easily for that very same reason.
But why are we continuing to try to "fix" something that is so
profoundly flawed? Why can't we make the right decision and fix it
once and for all?
10 0 2 +DO .. LOOP
which compiles to:
swap
>r >r >r
:1 2 rpick rover -
0= if branch :2
..
rover r+
branch :1
2: ...
(Probably some assembly required, but you catch my drift). Where ?DO
equals 1 +DO.
Hans Bezemer
hwf...@gmail.com
May 22, 2012, 12:54:51 PM5/22/12
to
> This change is to allow alternative implementations of LEAVE and UNLOOP
> with special compilation semantics. Especially for LEAVE, this is
> common practice.
It's very interesting most Forths assume compilation semantics such that your ANS compliant example breaks them. Perhaps it would be better to close this loophole by declaring LEAVE's immediacy. Then you could do things like
> with special compilation semantics. Especially for LEAVE, this is
> common practice.
: ?DONE POSTPONE IF POSTPONE LEAVE POSTPONE THEN
; IMMEDIATE
: FOO 0 DO I 3 = ?DONE LOOP ;
There are no signs in DPANS saying "There Be Dragons", so it's also possible to do something like this:
: FOO DUP 1+ >R . ['] R> EXECUTE . ; ok
4 FOO 4 ACCESS_VIOLATION ( SwiftForth )
Whenever I see "Interpretation semantics for this word are undefined" in the DPANS standard, I assume the word is IMMEDIATE and "compile-only". Why don't we just call a spade a spade and declare that this is the case?
-Brad
Elizabeth D. Rather
May 22, 2012, 1:33:14 PM5/22/12
to
"compile-only" basically *forbids* any other implementation. We know of
implementations in which DO, LOOP, etc., can be used interpretively
(Open Firmware is one example). That is not illegal. However, writers of
applications are warned by the "undefined" language that they cannot
*depend* on such a feature.
"Undefined" means exactly that: implementations are permitted to support
the behavior, issue an error message, erase your hard drive, post an
insulting status on Facebook, or anything else, and a user who tries to
test the limits of the behavior in question are warned that there is no
consistent or portable semantics there.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Stephen Pelc
May 22, 2012, 2:52:20 PM5/22/12
to
On Tue, 22 May 2012 09:54:51 -0700 (PDT), hwf...@gmail.com wrote:
>> This change is to allow alternative implementations of LEAVE and UNLOOP
>> with special compilation semantics. Especially for LEAVE, this is
>> common practice.
>
>It's very interesting most Forths assume compilation semantics such that
>your ANS compliant example breaks them. Perhaps it would be better to close
>this loophole by declaring LEAVE's immediacy.
The problem is then that immediacy implies that the compilation
>> This change is to allow alternative implementations of LEAVE and UNLOOP
>> with special compilation semantics. Especially for LEAVE, this is
>> common practice.
>
>It's very interesting most Forths assume compilation semantics such that
>your ANS compliant example breaks them. Perhaps it would be better to close
>this loophole by declaring LEAVE's immediacy.
semantics (behaviour) are the same as the interpretation
behaviour. It is better that words with undefined interpretation
semantics only have a specified run-time.
>Whenever I see "Interpretation semantics for this word are undefined"
>in the DPANS standard, I assume the word is IMMEDIATE and "compile-only".
>Why don't we just call a spade a spade and declare that this is the case?
IMMEDIATE are only IMMEDIATE because the standard says they have to
be.
Note that I am only talking about desktopsystems here. In standalone
embedded systems immediacy is still a useful attribute.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
BruceMcF
May 22, 2012, 6:38:03 PM5/22/12
to
On May 9, 1:42 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Problem: LEAVE and UNLOOP are defined to have no interpretation
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body.
I do not believe that this premise is valid.
> Problem: LEAVE and UNLOOP are defined to have no interpretation
> semantics, but an execution semantics. This implies that ['] LEAVE
> EXECUTE is equivalent to LEAVE within a loop body.
(1) ['] clearly specifies that it gives the same result as ' does when
interpreting.
(2) ' clearly specifies that *when interpreting*
' foo EXECUTE
... is the same as interpreting "foo".
(3) Thus ['] foo EXECUTE while compiling should give the
interpretation semantics of a word.
(4) LEAVE and UNLOOP are specified to have undefined interpreter
semantics, and so ['] LEAVE EXECUTE which while compiling is *not*
required to be equivalent to LEAVE within a loop body.
*However* my view is that there is still merit to one part of this
proposal. This is based on a point regarding which there is no
consensus, and upon which I appear to differ for Bernd, who has
suggested in another forum that this may be because his perspective is
too abstract for my humble mental capacities. And that may very well
be the case, so if I am wrong on this point, I'll need the assistance
of a somewhat less than lofty explanation why.
This goes to the heart of the notion of what "execution semantics" are
and what it implies for a word to be specified with special
compilation semantics. I have always had a tendency to view the first
clause in the specification of the term "execution" as the primary
clause. This clause is highlighted in the quote of relevant section
with * marks:
"3.4.3.1 Execution semantics"
"The execution semantics of each Forth definition are specified in
an Execution: section of its glossary entry. When a definition has
only one specified behavior, the label is omitted."
"*Execution may occur implicitly, when the definition into which it
has been compiled is executed*, or explicitly, when its execution
token is passed to EXECUTE. The execution semantics of a syntactically
correct definition under conditions other than those specified in this
Standard are implementation dependent."
"Glossary entries for defining words include the execution
semantics for the new definition in a name Execution: section."
What is not mentioned in the first paragraph of the specification is
that not all definitions have an "Execution:" section.
In my view, the special cases are implied by the highlighted section:
"Execution may occur implicitly, when the definition into which it has
been compiled is executed."
In most cases, the execution semantics are atomic. They occur at
execution time of the word into which the execution semantics have
been compiled, and all that is required to get that is for the system
to be in compilation state when encountering the word in the source.
However, in some cases, the execution semantics are not atomic. [CHAR]
must parse the following token at compile time to obtain the
character, which is placed on the stack at execution time, so correct
execution is contingent on both a compile-time and a run-time action.
THEN must find a valid orig on the compilation structures stack at
compile time, in order to be the position at which execution resumes
following, eg, the run-time of IF consuming a zero.
In scanning through the Standard, every instance where there is no
"Execution:" section, the situation involves this kind of non-atomic
execution semantics.
While the UNLOOP semantics are atomic, and properly specified, the
LEAVE semantics are not *necessarily* atomic, *unless* one provides an
implementation such as pushing the target leave address onto the
return stack. If one implements LEAVE as an unconditional branch,
tracking the LEAVE origins in some way outside of the compilation
structures stack, then the semantics are not in fact atomic.
This may have been overlooked because the former was the most common
LEAVE implementation in the early 90's, or because the record keeping
for the branch version of LEAVE is explicitly somewhere other than the
compilation structures stack, but in any event, LEAVE is, in my view,
properly defined as having special compilation semantics, as the other
structure words are.
I view UNLOOP as having atomic execution semantics similar to RDROP
and EXIT, and so I do not support the proposal with respect to UNLOOP.
> Solution: Remove "Execution:" from the definition of LEAVE.
> Insert instead
> Compilation: ( -- )
> Append the run-time semantics given below to the current
> definition.
>
> Run-Time:
> Rationale:
> This change is to allow alternative implementations of LEAVE with special
> Compilation: ( -- )
> Append the run-time semantics given below to the current
> definition.
>
> Run-Time:
> Rationale:
> compilation semantics. This is common practice.
Bernd Paysan
May 29, 2012, 12:50:37 PM5/29/12
to
BruceMcF wrote:
> "*Execution may occur implicitly, when the definition into which it
> has been compiled is executed*, or explicitly, when its execution
> token is passed to EXECUTE. The execution semantics of a syntactically
> correct definition under conditions other than those specified in this
> Standard are implementation dependent."
>
> "Glossary entries for defining words include the execution
> semantics for the new definition in a name Execution: section."
>
> What is not mentioned in the first paragraph of the specification is
> that not all definitions have an "Execution:" section.
>
> In my view, the special cases are implied by the highlighted section:
> "Execution may occur implicitly, when the definition into which it has
> been compiled is executed."
Yes, but that is added run-time code. There is an OR in the statement
> "*Execution may occur implicitly, when the definition into which it
> has been compiled is executed*, or explicitly, when its execution
> token is passed to EXECUTE. The execution semantics of a syntactically
> correct definition under conditions other than those specified in this
> Standard are implementation dependent."
>
> "Glossary entries for defining words include the execution
> semantics for the new definition in a name Execution: section."
>
> What is not mentioned in the first paragraph of the specification is
> that not all definitions have an "Execution:" section.
>
> In my view, the special cases are implied by the highlighted section:
> "Execution may occur implicitly, when the definition into which it has
> been compiled is executed."
above, and I imply that execution semantics has both caracteristics:
Either where it has been comiled to, *or* when it is executed. The
declaration of an execution semantics also implies that there is an xt,
which can be appended to the current definition using COMPILE,. This is
often not the case with LEAVE, but typically works with UNLOOP.
> In most cases, the execution semantics are atomic. They occur at
> execution time of the word into which the execution semantics have
> been compiled, and all that is required to get that is for the system
> to be in compilation state when encountering the word in the source.
>
> However, in some cases, the execution semantics are not atomic. [CHAR]
> must parse the following token at compile time to obtain the
> character, which is placed on the stack at execution time, so correct
> execution is contingent on both a compile-time and a run-time action.
semantics. [CHAR] is usually implemented as immediate word, and its
execution semantics therefore are equal to its compilation semantics.
The run-time semantics from [CHAR] is equal to that of POSTPONE LITERAL.
> THEN must find a valid orig on the compilation structures stack at
> compile time, in order to be the position at which execution resumes
> following, eg, the run-time of IF consuming a zero.
>
> In scanning through the Standard, every instance where there is no
> "Execution:" section, the situation involves this kind of non-atomic
> execution semantics.
>
> While the UNLOOP semantics are atomic, and properly specified, the
> LEAVE semantics are not *necessarily* atomic, *unless* one provides an
> implementation such as pushing the target leave address onto the
> return stack. If one implements LEAVE as an unconditional branch,
> tracking the LEAVE origins in some way outside of the compilation
> structures stack, then the semantics are not in fact atomic.
>
> This may have been overlooked because the former was the most common
> LEAVE implementation in the early 90's, or because the record keeping
> for the branch version of LEAVE is explicitly somewhere other than the
> compilation structures stack, but in any event, LEAVE is, in my view,
> properly defined as having special compilation semantics, as the other
> structure words are.
>
> I view UNLOOP as having atomic execution semantics similar to RDROP
> and EXIT, and so I do not support the proposal with respect to UNLOOP.
Gforth. It corrects the locals stack (if there is anything to correct,
i.e. if the word has locals), and then compiles ;S, the return
primitive.
BruceMcF
May 29, 2012, 1:38:52 PM5/29/12
to
On May 29, 12:50 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> BruceMcF wrote:
> > "*Execution may occur implicitly, when the definition into which it
> > has been compiled is executed*, or explicitly, when its execution
> > token is passed to EXECUTE. The execution semantics of a syntactically
> > correct definition under conditions other than those specified in this
> > Standard are implementation dependent."
> > "Glossary entries for defining words include the execution
> > semantics for the new definition in a name Execution: section."
> > What is not mentioned in the first paragraph of the specification is
> > that not all definitions have an "Execution:" section.
> > In my view, the special cases are implied by the highlighted section:
> > "Execution may occur implicitly, when the definition into which it has
> > been compiled is executed."
> Yes, but that is added run-time code.
Yes, when converted from the standard specification of behavior into
> BruceMcF wrote:
> > "*Execution may occur implicitly, when the definition into which it
> > has been compiled is executed*, or explicitly, when its execution
> > token is passed to EXECUTE. The execution semantics of a syntactically
> > correct definition under conditions other than those specified in this
> > Standard are implementation dependent."
> > "Glossary entries for defining words include the execution
> > semantics for the new definition in a name Execution: section."
> > What is not mentioned in the first paragraph of the specification is
> > that not all definitions have an "Execution:" section.
> > In my view, the special cases are implied by the highlighted section:
> > "Execution may occur implicitly, when the definition into which it has
> > been compiled is executed."
> Yes, but that is added run-time code.
implementation, it implies added run-time code.
It does not, however, imply "nothing but adding run-time code", since
"into which is has been compiled" is not *restricted to* merely
appending execution semantics. That is the *default* compilation
semantics, but "compilation" in *general* terms applies to all the
*different* compilation behaviors within the scope of the standard.
Bernd Paysan
May 30, 2012, 1:41:47 PM5/30/12
to
BruceMcF wrote:
>> > In my view, the special cases are implied by the highlighted
>> > section: "Execution may occur implicitly, when the definition into
>> > which it has been compiled is executed."
>
>> Yes, but that is added run-time code.
>
> Yes, when converted from the standard specification of behavior into
> implementation, it implies added run-time code.
>
> It does not, however, imply "nothing but adding run-time code", since
> "into which is has been compiled" is not *restricted to* merely
> appending execution semantics. That is the *default* compilation
> semantics, but "compilation" in *general* terms applies to all the
> *different* compilation behaviors within the scope of the standard.
Ok, let's go back to the assumption:
>> > In my view, the special cases are implied by the highlighted
>> > section: "Execution may occur implicitly, when the definition into
>> > which it has been compiled is executed."
>
>> Yes, but that is added run-time code.
>
> Yes, when converted from the standard specification of behavior into
> implementation, it implies added run-time code.
>
> It does not, however, imply "nothing but adding run-time code", since
> "into which is has been compiled" is not *restricted to* merely
> appending execution semantics. That is the *default* compilation
> semantics, but "compilation" in *general* terms applies to all the
> *different* compilation behaviors within the scope of the standard.
If it has execution semantics, it has an xt.
An xt can be COMPILE,d to generate code. This is "appending run-time
code".
In a traditional system, there is little choice what COMPILE, can do -
it is usually equivalent to , or similar. If you want compilation
semantics code to be executed at compile-time, you use the IMMEDIATE
flag. So in a mostly traditional implementation, going through
"execution semantics" IMHO is too strict.
In a smart-COMPILE, system like VFX, COMPILE, can do all kind of things
at compile time. Going through "execution semantics" might be
appropriate, but does not adequately describe what happens.
BruceMcF
May 30, 2012, 6:33:42 PM5/30/12
to
On May 30, 1:41 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Ok, let's go back to the assumption:
> If it has execution semantics, it has an xt.
If it has discrete execution semantics, there should be an xt for
> Ok, let's go back to the assumption:
> If it has execution semantics, it has an xt.
those. Anf from the specification of ' and ['] if it has defined
interpretation semantics that are distinct from the discrete execution
semantics, there should be an xt for those as well.
> An xt can be COMPILE,d to generate code. This is "appending run-time
> code".
time behavior is what the specification says.
> In a traditional system, there is little choice what COMPILE, can do -
> it is usually equivalent to , or similar. If you want compilation
> semantics code to be executed at compile-time, you use the IMMEDIATE
> flag. So in a mostly traditional implementation, going through
> "execution semantics" IMHO is too strict.
IMMEDIATE flag still serves to *identify* the execution semantics,
which are provided for in part at compile-time and in part at run-
time.
0 new messages