pfe-header-ext
Prev? | pfe Forth Wordset List | ?Next

## Name

pfe-header-ext ? Header Navigation

## Synopsis

`BODY> ( pfa -- cfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`>LINK ( cfa -- lfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`LINK> ( lfa -- cfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`>NAME ( cfa -- nfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`NAME> ( nfa -- cfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`L>NAME ( lfa -- nfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`N>LINK ( nfa -- lfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`NAME>STRING ( name-token -- str-ptr str-len ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`LATEST ( -- nfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`>FFA ( nfa -- ffa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`FFA> ( ffa -- nfa ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`NAME-FLAGS@ ( nfa -- nfa-flags ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`NAME-FLAGS! ( nfa-flags nfa -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`HEADER, ( str-ptr str-len -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`$HEADER ( bstring -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`SMUDGE ?=>? (` | `)`; | ?

`[FORTH]`;
?

`HIDE ( -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`REVEAL ( -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`RECURSIVE ( -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`(CHECK-DEPRECATED:) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`ALIAS ( some-xt* "name" -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`IS ( xt-value [word] -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`DEFER! ( xt-value xt-defer -- ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`DEFER@ ( xt1 -- xt2 ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

`ACTION-OF ( [word] -- xt-value ) ?=>? (` | `)`; | ?

`[FORTH]`;
?

## Description

BODY> ( pfa -- cfa ) => [FORTH]

trying to convert a pointer to the parameter-field (PFA) to point then to the corresponding code-field (CFA) - note that this is not necessarily the inverse of `>BODY` instead it is a fast implementation assuming a `VARIABLE` thing had been used. Every use of "BODY>" is warned in the logfile.

      implementation-specific simulation:
        : BODY&gt; CELL - ;

>LINK ( cfa -- lfa ) => [FORTH]

converts a pointer to the code-field (CFA) to point then to the corresponding link-field (LFA) - in some configurations this can be a very slow operation since the system might need to walk through all header-words in the system, looking for a `>NAME` that has the cfa and *then* returning the "N>LINK" result here - which might be none at all if the word is a `:NONAME`. Use always `>NAME` and treat this word as non-portable just like any assumption about the contents of the `>LINK`-field. Only in fig-mode and for traditional fig-mode programs, this word may possibly have enough extra assertions to be somewhat reliable. (and fig-mode did not know about `SYNONYM`s - see note at `LINK>`).

LINK> ( lfa -- cfa ) => [FORTH]

converts a pointer to the link-field (LFA) to point then to the corresponding code-field (CFA)

BEWARE: this one does not care about `SYNONYM`s and it is the only way to get at the data of a `SYNONYM`. Therefore, if you have a synonym called A for an old word B then there is a different result using "NAME>" on an A-nfa or using "N>LINK LINK>" since the first "NAME>" will return the xt of B while the latter will return the xt of A - but executing an xt of A is an error and it will `THROW`

this difference is intentional to allow knowledgable persons to do weird things looking around in the dictionary. The forth standard words will not give you much of a chance to get hold of the nfa of a `SYNONYM` word anyway - asking `FIND` for a word A will return the execution token of B immediatly and "NAME>" on that one lead to the nfa of B and not that of A.

>NAME ( cfa -- nfa ) => [FORTH]

converts a pointer to the code-field (CFA) to point then to the corresponding name-field (NFA)

      implementation-specific simulation:
        : &gt;NAME  &gt;LINK L&gt;NAME ;

NAME> ( nfa -- cfa ) => [FORTH]

converts a pointer to the name-field (NFA) to point then to the corresponding code-field (CFA)

In all cases but a `SYNONYM` the pfe will behave not unlike the original fig-forth did - being identical to `N>LINK` `LINK>` .

L>NAME ( lfa -- nfa ) => [FORTH]

converts a pointer to the link-field (LFA) to point then to the corresponding name-field (CFA) - this one is one of the slowest operation available. One should always use the inverse operation `N>LINK` and cache an older value if that is needed. Some words might be linked but they do not have a name-field (just the other fields) but this word can not detect that and will try to look into the bits of the dictionary anway in the assumption that there is something - and if done in the wrong place it might even segfault. Only in fig-mode and for traditional fig-mode programs, this word may possibly have enough extra assertions to be somewhat reliable. (and fig-mode did not know about `SYNONYM`s - see note at `LINK>`).

      implementation-specific configure-dependent fig-only simulation:
      : L&gt;NAME BEGIN DUP C@ 128 AND 0= WHILE 1- REPEAT ;

N>LINK ( nfa -- lfa ) => [FORTH]

converts a pointer to the name-field (NFA) to point then to the corresponding link-field (LFA) - this operation is quicker than the inverse `L>NAME`. This word is a specific implementation detail and should not be used by normal users - instead use always `NAME>` which is much more portable. Many systems may possibly not even have a `>LINK`-field in the sense that a `@` on this adress will lead to another `>NAME`. Any operation on the resulting `>LINK`-adress is even dependent on the current configuration of PFE - only in fig-mode you are asserted to have the classic detail. (and fig-mode did not know about `SYNONYM`s - see note at `LINK>`).

      implementation-specific configure-dependent fig-only simulation:
        : N&gt;LINK  C@ + ;

NAME>STRING ( name-token -- str-ptr str-len ) => [FORTH]

convert a name-token into a string-span, used to detect the name for a word and print it. The word `ID.` can be defined as

      : ID. NAME&gt;STRING TYPE ;

the implementation of `NAME>STRING` depends on the header layout that is defined during the configuration of the forth system.

      : NAME&gt;STRING COUNT 31 AND ; ( for fig-like names )
      : NAME&gt;STRING COUNT ;        ( default, name is a simple counted string )
      : NAME&gt;STRING @ ZCOUNT ;     ( name-token is a pointer to a C-level string )
      : NAME&gt;STRING COUNT 31 AND   ( hybrid of fig-like and zero-terminated )
           DUP 31 = IF DROP 1+ ZCOUNT THEN
      ;
      : NAME&gt;STRING HEAD:: COUNT CODE:: PAD PLACE PAD ; ( different i86 segments )

LATEST ( -- nfa ) => [FORTH]

return the NFA of the lateset definition in the `CURRENT` vocabulary

>FFA ( nfa -- ffa ) obsolete => [FORTH]

converts a pointer to the name-field (NFA) to point then to the corresponding flag-field (FFA) - in traditinal Forth this is the same address. pfe _can_ do different.

      implementation-specific configure-dependent simulation:
        : FFA  1- ;

FFA> ( ffa -- nfa ) obsolete => [FORTH]

converts a pointer to the flag-field (FFA) to point then to the corresponding name-field (NFA) - in traditinal Forth this is the same address. pfe _can_ do different.

      implementation-specific configure-dependent simulation:
        : FFA  1+ ;

NAME-FLAGS@ ( nfa -- nfa-flags ) => [FORTH]

get the nfa-flags that corresponds to the nfa given. Note that in the fig-style would include the nfa-count in the lower bits. (see `NAME-FLAGS!`)

NAME-FLAGS! ( nfa-flags nfa -- ) => [FORTH]

set the nfa-flags of nfa given. Note that in the fig-style the nfa-flags would include the nfa-count in the lower bits - therefore this should only set bits that had been previously retrieved with `NAME-FLAGS@`

      : IMMEDIATE LAST @ NAME-FLAGS@ IMMEDIATE-MASK OR LAST @ NAME-FLAGS! ;

HEADER, ( str-ptr str-len -- ) => [FORTH]

`CREATE` a new header in the dictionary from the given string, without CFA

      usage: : VARIABLE  BL WORD COUNT HEADER, DOVAR , ;

$HEADER ( bstring -- ) => [FORTH]

`CREATE` a new header in the dictionary from the given string with the variable runtime (see `HEADER,` and `CREATE:`)

      usage: : VARIABLE  BL WORD $HEADER ;

SMUDGE - no description, sorry

HIDE ( -- ) => [FORTH]

the FIG definition toggles the `SMUDGE` bit, and not all systems have a smudge bit - instead one should use `REVEAL` or `HIDE`

      : HIDE LAST @ FLAGS@ SMUDGE-MASK XOR LAST @ FLAGS! ;

REVEAL ( -- ) => [FORTH]

the FIG definition toggles the `SMUDGE` bit, and not all systems have a smudge bit - instead one should use `REVEAL` or `HIDE`

      : REVEAL LAST @ FLAGS@ SMUDGE-MASK INVERT AND LAST @ FLAGS! ;
      : REVEAL LAST @ CHAIN-INTO-CURRENT ;

RECURSIVE ( -- ) => [FORTH]

`REVEAL` the current definition making it `RECURSIVE` by its own name instead of using the ans-forth word to `RECURSE`.

      ' REVEAL ALIAS RECURSIVE IMMEDIATE

(CHECK-DEPRECATED:) - no description, sorry

ALIAS ( some-xt* "name" -- ) [EXT] => [FORTH]

create a defer word that is initialized with the given x-token. `DO-ALIAS`

IS ( xt-value [word] -- ) => [FORTH]

set a `DEFER` word (in pfe: set the DOES-field - which is the BODY-field in ans-mode and therefore the same as `TO` / in fig-mode the DOES-field is one cell higher up than for a `CREATE:` `VARIABLE` Use `IS` freely on each DOES-words in both modes).

      : IS '
        STATE @ IF LITERAL, POSTPONE &gt;DOES-BODY POSTPONE !
        ELSE &gt;DOES-BODY ! THEN
      ; IMMEDIATE

DEFER! ( xt-value xt-defer -- ) => [FORTH]

A Forth200x definition that is not very useful.

DEFER@ ( xt1 -- xt2 ) => [FORTH]

get the execution token xt2 that would be executed by the `DEFER` identified by xt1.

This command is used to obtain the execution contents of a deferred word. A typical use would be to retrieve and save the execution behavior of the deferred word, set the deferred word to a new behavior, and then later restore the old behavior.

If the deferred word identified by _xt1_ is associated with some other deferred word, _xt2_ is the execution token of that other deferred word. To retrieve the execution token of the word currently associated with that other deferred word, use the phrase DEFER@ DEFER@ .

Experience: BEHAVIOR was used many years in OpenBoot and OpenFirmware systems.

In PFE it is the inverse of an `IS` operation and it will never fail if applied to a word with atleast a body. That's just like `IS` can be applied to almost every `DOES>` word where `DEFER@` will get the value back.

ACTION-OF ( [word] -- xt-value ) => [FORTH]

get the `BEHAVIOR` of a `DEFER` word when executed. If being compiled then the ACTION-OF will be the value of [word] at the time of execution and not that of compilation time (non-constant).

In PFE it does actually pick whatever is stored in the DOES-field of a word and therefore ACTION-OF may applied to all DOES-words.

Prev? | Up | ?Next
pfe-gforth-ext? | Home | ?pfe-help-ext