www.delorie.com/gnu/docs/gforth/gforth_190.html   search  
Buy GNU books!

Gforth Manual

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5.23.2 Common Assembler

The assemblers in Gforth generally use a postfix syntax, i.e., the instruction name follows the operands.

The operands are passed in the usual order (the same that is used in the manual of the architecture). Since they all are Forth words, they have to be separated by spaces; you can also use Forth words to compute the operands.

The instruction names usually end with a ,. This makes it easier to visually separate instructions if you put several of them on one line; it also avoids shadowing other Forth words (e.g., and).

Registers are usually specified by number; e.g., (decimal) 11 specifies registers R11 and F11 on the Alpha architecture (which one, depends on the instruction). The usual names are also available, e.g., s2 for R11 on Alpha.

Control flow is specified similar to normal Forth code (see section 5.8.4 Arbitrary control structures), with if,, ahead,, then,, begin,, until,, again,, cs-roll, cs-pick, else,, while,, and repeat,. The conditions are specified in a way specific to each assembler.

Note that the register assignments of the Gforth engine can change between Gforth versions, or even between different compilations of the same Gforth version (e.g., if you use a different GCC version). So if you want to refer to Gforth's registers (e.g., the stack pointer or TOS), I recommend defining your own words for refering to these registers, and using them later on; then you can easily adapt to a changed register assignment. The stability of the register assignment is usually better if you build Gforth with --enable-force-reg.

In particular, the return stack pointer and the instruction pointer are in memory in gforth, and usually in registers in gforth-fast. The most common use of these registers is to dispatch to the next word (the next routine). A portable way to do this is to jump to ' noop >code-address (of course, this is less efficient than integrating the next code and scheduling it well).

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003