For words built into Gforth, the documentation specifies the semantics.
Most words have default compilation semantics. For such words (e.g.,
!, see Memory Access) the documentation describes the
interpretation semantics without explicitly labeling as such. The
compilation semantics of these words is to compile the interpretation
semantics into the current definition; the stack effect of performing
the default compilation semantics is ( -- ).
Some words have non-default compilation semantics. This is either
indicated by labels for interpretation, compilation, and/or run-time
in the stack effects (e.g., for IF, see Arbitrary control structures), or by having separate paragraphs for interpretation,
compilation, and/or run-time in the prose (e.g., for S",
see String and Character literals).
You may wonder about the run-time semantics mentioned in the previous
paragraphs. For some words (e.g., if), the compilation
semantics compiles something that is not the interpretation/execution
semantics. We (and the standard) describe the behaviour of the code
that these words compile with under the label “run-time semantics”;
if you see “run-time” in a word description (e.g., in its stack
effect), that usually refers to run-time semantics that the
compilation semantics of the word compiles.
Concerning the description of the various semantics, both the standard and this manual describe the interpretation/execution semantics of words with default semantics without preceding these semantics with a label (the label “execution” or “interpretation” would be appropriate). The compilation semantics of such words are the implied default compilation semantics (see What sematics do normal definitions have?).
For words that have some non-default semantics, the standard specifies the different semantics of the word in separate subsections, each preceded with a label (“interpretation:”, “compilation:”, and, if necessary, “execution:” or “run-time:”21). This manual often takes a more informal approach. The approach taken in this manual may be more accomodating for everyday use, while the standard approach is more precise for reasoning about details of the language.
In some cases the standard leaves the subsection for interpretation or compilation semantics away, and leaves it to the default mechanism to derive those semantics from execution semantics.