Closed TG9541 closed 3 years ago
This is now getting more serious ;-)
I've found a problem in >REL
, the relative addressing compiler overlay for IF ... ELSE ... THEN
:
I hadn't realized that ]
isn't flagged IMMEDIATE
(it doesn't need to be since it starts the compiler) and had compiled it with [COMPILE]
. This has no effect whatsoever unless that's an alias for POSTPONE
. The problem is easy to fix ( -> #419 ) but [COMPILE]
masks such errors and one has to be careful when replacing that word.
Using POSTPONE in the lib worked fine. I'll now turn off the legacy words in defconf.inc
. If some code needs them they can be selected in a downstream build configuration (e.g. in globconf.inc
).
By default the aliases COMPILE
and [COMPILE]
are in the target
folder. Just take care not to use the [COMPILE]
alias on a non-IMMEDIATE word (which is now from now on "officially" an error).
More modern Forth implementations than eForth have long replaced
COMPILE
and[COMPILE]
with the more general word POSTPONE.The difference between the old and the new approach is this:
Compile a regular word: a:
: test1a COMPILE DROP ;
=><CALL XT-COMPILE><CALL XT-DROP>
b:: test1b POSTPONE DROP ;
=><LIT XT-DROP><CALL XT-CALL,>
Compile an IMMEDIATE word: a:
: test2a [COMPILE] IF ;
=><CALL XT-IF>
b:: test2b POSTPONE IF ;
=><CALL XT-IF>
When used as "macros" or directly as
IMMEDIATE
the wordstest1a
-test2a
andtest1b
-test2b
perform the same thing (COMPILE
intest1b
has to work around any STM8 eForth code optimization features which can be a big issue)There is an edge case when
[COMPILE]
is used to compile a regular word: a:: test3a [COMPILE] DROP ;
=><CALL XT-DROP>
b:: test3b POSTPONE DROP ;
=><LIT XT-DROP><CALL XT-CALL,>
Other edge cases exist if any of the words
POSTPONE
,COMPILE
or[COMPILE]
is used with words defined byCREATE
,CONSTANT
orVARIABLE
. I'll have to check what the "the standard` has to say about that.Before doing any such change I'd like to get some input from the community.
ALIAS
ing the legacy words toPOSTPONE
an acceptable solution?