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

Groups > comp.lang.forth > #135087

Re: ciforth model

Show all headers | View raw

On Sat, 18 Apr 2026 10:26:11 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> albert@spenarnc.xs4all.nl writes:
> >The argument was that an extreme impractical Forth can be implemented
> >with this model as guideline, to counter the argument of extreme waste
> >that I expected.
> 
> The users have voted with their feet: They usually have used the
> "extremely wasteful" fig-Forth with the default settings (names with
> up to 31-char) rather than using the "extremely impractical" option to
> only store the first n chars of a name (with n being configurable in
> fig-Forth).  "Wastefulness" won over "Impracticality" so convincingly
> that even Forth, Inc. switched from "impracticality" to
> "wastefulness", as well as almost everyone else.  The exception is
> Chuck Moore, who continues with the "impractical" approach in
> ColorForth.  Even in the Forth universe, few people seem to use
> ColorForth and I have not heard of systems that follow its approach to
> names.
> 
> Concerning memory consumption, Gforth's development version includes quite a bit of meta-information for two purposes:
> 
> 1) How the threaded code relates to the source code, not just where
>    each definition starts, but also where words are used.
> 
> 2) How the machine code addresses relate to what is COMPILE,d, to get
> proper decompilation with SEE-CODE, SIMPLE-SEE, and SEE.
> 
> Both sets of informations are in big tables that are stored
> out-of-line, not with the headers, and each takes about as much space
> as the inline stuff (headers, threaded code, other bodies); the
> information where each definition is defined is stored in the headers,
> however.  The result is that gforth.fi takes 2.3MB on my system; for
> comparison, the inline dictionary stuff is 686464 bytes, the native
> code of 465671 bytes for gforth-fast and 892251 for gforth (also
> out-of-line, both not in the image).
> 
> One may consider this wasteful, but I consider it good use of the RAM
> that our machines have; my PC from 1993 had 16MB, the one from 2015
> 16GB, my current one 64GB.
> 
> Concerning header size, here's what we have in Gforth (on a 64-bit system):
> 
> here 5 constant five here over - dump 
> 403AC9C0: 20 20 20 20  66 69 76 65 - 04 00 00 00  00 00 00 00      five........
> 403AC9D0: 08 C7 3A 40  00 00 00 00 - 81 EA A1 9D  EA 55 00 00  ..:@.........U..
> 403AC9E0: 60 AF 30 40  00 00 00 00 - 05 00 00 00  00 00 00 00  `.0@............
> 
> I.e., 6 cells for a word with a name that fits in one cell, and one
> cell of body.  The cells are:
> 
> 403AC9C0: Name padded with spaces at the front to align it to a cell boundary
> 403AC9C8: Name length and flags
> 403AC9D0: link field (pointer to previous word in the same wordlist)
> 403AC9D8: header methods (pointer to a method table)
> 403AC9E0: code field (contains the code address of docon in this case)
> 403AC9E8: body aka parameter field, contains the value in this case
> 
> For more information, read
> 


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   

Your example of five becomes

align-h here-h 5 constant five here-h over - dump
000000007227A0 04 46 49 56 45 00 00 00 C0 27 72 00 30 68 42 00 .FIVE....'r.0hB.
000000007227B0 F8 D0 71 00 03 00 10 00 20 18 00 00 50 00 A0 00 ..q..... ...P...
000000007227C0 26 05 25 00 00 00 00 00 00 00 00 00 00 00 00 00 &.%.............

I have the counted name aligned and zero padded at the start.
This will allow to compare 8 bytes at a time

: NCOMP  ( addr  addr'  - f) \ compare counted name strings strings 0= match     
    dup c@ 1+ 
        0 ?do 
        over i + @ over i + @ 
        <> if 2drop unloop true exit then
        8 +loop 2drop false ;

I have checked forth-wordlist and 71.5% of all words will require only one
comparison. 1.5% will require more then 2 comparisons.

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.

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

ht-execute executes the NT. [n'] returns the NT

C", TO, ACTION-OF, IS and S\" are implemented in similar ways.

Now the recognizers are starting to make good sense!

BR
Peter



> @InProceedings{paysan&ertl19,
>   author =       {Bernd Paysan and M. Anton Ertl},
>   title =        {The new {Gforth} Header},
>   crossref =     {euroforth19},
>   pages =        {5--20},
>   url =          {http://www.euroforth.org/ef19/papers/paysan.pdf},
>   url-slides =   {http://www.euroforth.org/ef19/papers/paysan-slides.pdf},
>   video =        {https://wiki.forth-ev.de/doku.php/events:ef2019:header},
>   OPTnote =      {refereed},
>   abstract =     {The new Gforth header is designed to directly
>                   implement the requirements of Forth-94 and
>                   Forth-2012.  Every header is an object with a fixed
>                   set of fields (code, parameter, count, name, link)
>                   and methods (\texttt{execute}, \texttt{compile,},
>                   \texttt{(to)}, \texttt{defer@}, \texttt{does},
>                   \texttt{name>interpret}, \texttt{name>compile},
>                   \texttt{name>string}, \texttt{name>link}).  The
>                   implementation of each method can be changed
>                   per-word (prototype-based object-oriented
>                   programming).  We demonstrate how to use these
>                   features to implement optimization of constants,
>                   \texttt{fvalue}, \texttt{defer}, \texttt{immediate},
>                   \texttt{to} and other dual-semantics words, and
>                   \texttt{synonym}.}
> }
> 
> @Proceedings{euroforth19,
>   title = 	 {35th EuroForth Conference},
>   booktitle = 	 {35th EuroForth Conference},
>   year = 	 {2019},
>   key =		 {EuroForth'19},
>   url =          {http://www.euroforth.org/ef19/papers/proceedings.pdf}
> }
> 
> There have been a few changes since that paper: The body address is
> now used as nt and xt, and the "name length and flags" field has
> gained another flag or two.
> 
> - 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 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