Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135093

Re: ciforth model

Show all headers | View raw

On Sat, 23 May 2026 18:12:20 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> peter <peter.noreply@tin.it> writes:
> >I did go ahead and change the LXF64 header to something more like the 
> >gforth one! This is what it looks like:
> >
> >\ offset length purpose
> >\ -24-8n 8+8n   counted name aligned and patched with zeros n=0,1,2,3 
> >\ -16   8       xt (xt token + xt native)
> >\ -8    4       link
> >\ -4    2       Tlen Token code length
> >\ -2    2       Nlen Native code length
> >\  0    1       flag byte               <- NT points here
> >\  1    1       offset to name from NT
> >\  2    2       unused
> >\  4    4       pointer to translate-name
> >\  8    Tlen    token code   
> ...
> >The other interesting change I did was to put in a link to translate-name.
> >Each word now knows how to interpret, compile and postpone itself!
> >
> >I have now 3 standard word types
> >translate-name
> >translate-name-immediate
> >translate-name-macro
> >
> >This takes away all checks of the flag and following conditionals.
> >I could actually remove the flag byte.
> 
> In Gforth we did this by making the implementations of NAME>INTERPRET
> and NAME>COMPILE word-specific:
> 
> Words with default compilation semantics have DEFAULT-NAME>COMP als
> implementation, immediate words have IMM>COMP as implementation, and
> other words (e.g., S") have other implementations.
> 
> \ the actual implementation is a bit different, but this is the
> \ easier-to-understand version.
> : default-name>comp ( nt -- xt1 xt2 )
>   name>interpret ['] compile, ;
> 
> : imm>comp ( nt -- xt1 xt2 )
>   name>interpret ['] execute ;

I studied your linked document and slides a understood it worked 
something like that. Seeing your VT table gave me the idea to
put in a link to the translate record

> 
> In Gforth translate-name does not differentiate between different
> kinds of words; it always produces "nt translate-name" on success, and
> NAME>COMPILE takes care of the differences.  My guess us that you do
> it differently because you do not have NAME>COMPILE.  Am I corrent?

No I have also name>compile, but it is not used anymore

> 
> >I also introduced SET-TRANSLATOR that sets the translator of the 
> >last defined word. This lets me define all state smart words 
> >without state! S" illustrates this:
> >
> >: [S"]
> >    34 parse slit ; immediate
> >
> >' ht-execute    
> >:noname drop postpone [S"] ;
> >:noname drop [n'] [S"] lit, postpone ht-execute  ;
> >create translate-s"
> >, , ,
> >
> >: S"
> >    34 parse dup >r pocket dup >r swap  move  r> r> ;
> > 
> >translate-s" set-translator
> 
> Interesting.
> 
> >ht-execute executes the NT. [n'] returns the NT
> 
> So you have NTs.  Do you have NT>COMPILE?  If so, the differences
> between default and immediate and other words should already be
> implemented there.

HT stands for header token. I started using that long before the NT
was introduced. They are of course the same.

name>compile was defined as:

: NAME>COMPILE   ( nt -- w xt )
    dup nt>flag c@ 64 and if ['] ht-execute else ['] ht-compile, then ;

Now it is

: NAME>COMPILE   ( nt -- w xt )
    dup nt>trans l@ cell+ @ ;

ht-compile, is defined as

: HT-COMPILE, ( ht -- )
	dup nt>flag c@ 32 and 
    if  ht-expand-macro exit then
	ht-,call ;	

If the word is a macro it is expanded otherwise an ordinary 
call is compiled.
About 50% of all words are macros.

With the 3 translate-name-xxx all the flag testing is gone!
The right execution path is set at creation time.

The ability to set a specific translation record for the 
state smart words comes as an extra benefit.

To really integrate the recognizers well I made REC-NAME the
primary name finding function. Fnd-name is then defined as:

: FIND-NAME ( caddr u -- ht | 0)
	rec-name dup if drop then ;

Translate-none returns a null pointer in my system.

BR
Peter

> - anton

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

ciforth model albert@spenarnc.xs4all.nl - 2026-04-16 15:38 +0200
  Re: ciforth model dxf <dxforth@gmail.com> - 2026-04-17 11:44 +1000
    Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-17 07:29 +0000
      Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-17 12:10 +0200
        Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-18 10:26 +0000
          Re: ciforth model peter <peter.noreply@tin.it> - 2026-04-18 18:11 +0200
          Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-18 20:57 +0200
            Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-19 11:08 +0000
              Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-20 13:39 +0200
          Re: ciforth model peter <peter.noreply@tin.it> - 2026-05-21 10:28 +0200
            Re: ciforth model minforth <minforth@gmx.net> - 2026-05-22 12:04 +0200
            Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-23 18:12 +0000
              Re: ciforth model peter <peter.noreply@tin.it> - 2026-05-23 23:09 +0200
              Re: ciforth model peter <peter.noreply@tin.it> - 2026-05-24 10:07 +0200
                Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-25 13:34 +0000
      Re: ciforth model Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-21 19:39 +0200
      Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-22 22:48 +0200
        Re: ciforth model Paul Rubin <no.email@nospam.invalid> - 2026-04-24 10:38 -0700
          Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-25 11:54 +0200
            Re: ciforth model Paul Rubin <no.email@nospam.invalid> - 2026-04-25 13:22 -0700
              Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-26 14:05 +0200
  Re: ciforth model Paul Rubin <no.email@nospam.invalid> - 2026-04-17 00:27 -0700
    Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-17 12:13 +0200

csiph-web