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

Groups > comp.lang.forth > #135090

Re: ciforth model

Show all headers | View raw

Am 21.05.2026 um 10:28 schrieb peter:
> 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!

My approach from a different angle: minimize header size AND have
dual execution tokens for STATE-independent definitions

Header struct:  <name> (lfa,nfa,ccfa,cfa)
<name> name string
lfa   link field address to preceding header
nfa   pointer to <name>
ccfa  compile-time code field address
cfa   execution-time code field address

Different word types are recognised by comparing cfa with ccfa:
ccfa empty: "normal" word
cfa empty: compile-only word
cfa=ccfa: immediate word

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 peter <peter.noreply@tin.it> - 2026-05-27 10:42 +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