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

Groups > comp.lang.forth > #134934

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
> 
I like the idea to have the name at the beginning. I might try that also.
In ntf64/lxf64 I have a compact header! Your example becomes

n' five 16 - 32 dump
0000000071EFF0 08 F0 71 00 30 70 42 00 A8 EF 71 00 03 00 10 00 ..q.0pB...q.....
0000000071F000 A4 46 49 56 45 00 00 00 26 05 25 00 00 00 00 00 .FIVE...&.%.....

71EFF0: xt to token code
71EFF4: xt to native code
71EFF8: link field
71EFFC: lenght of token code
71EFFE: lenght of native code
71F000: flags (3 bits) and count (5 bits)
71F001: name zero extended to 8 byte alignment
71F008: token code 

Compilation is first to token code then this is sent to the native code 
generator
SEE decompiles the token code and SEEA the native code
Code Headers and Data have separate memory regions
A constant have no data associated to it. 
The constant is stored in the code
five in this example is a macro and will be inlined if called from 
another definition.

see five macro
Address   OP                         Instruction
0x71F008  26 05                      LIT1  5
0x71F00A  25                         RET
3 bytes, 2 instructions
ok

seea five
0x427030  48895DF8                    mov       qword [rbp-0x8], rbx
0x427034  48C7C305000000              mov       rbx, 0x5
0x42703B  488D6DF8                    lea       rbp, [rbp-0x8]
0x42703F  C3                          ret
16 bytes, 4 instructions

ticking a word gives a double xt

' five h. $0042´7030´0071´F008

This way I can store an xt and both the token and native code can use it.
It works as I compile the executable to be loaded at 0x400000.


BR
Peter

> For more information, read
> 
> @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 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