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

Groups > comp.lang.forth > #134936

Re: ciforth model

Show all headers | View raw

albert@spenarnc.xs4all.nl writes:
>In article <2026Apr18.122611@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>>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.

This is used for making backtraces more informative.

>>2) How the machine code addresses relate to what is COMPILE,d, to get
>>proper decompilation with SEE-CODE, SIMPLE-SEE, and SEE.

3) There is also the where table that records where each word is
actually used in the loaded source code, whether there is threaded
code for it or not; it records interpretive use as well as immediate
words where the threaded code is for a different word, if there is
threaded code at all.

>>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).
>
>In view that ctags understands Forth code this seems to be a duplicate
>effort.
>ctags --lang=forth *.frt

I have run ctags and etags with this option on the files from the Gray
directory, and both do not find any of the definitions of TERM (which
exist in calc.fs and oberon.fs); that's probably because they have
been defined with a user-defined defining word.

Due to this shortcoming of etags (and ctags), gforth has included
etags.fs since very early, which really understands Forth code,
because it hooks into the Gforth system and records a tag whenever a
named word is defined.  I dimly remember that we also have done ctags
support (for vi users), but do not find anything about it at the
moment.

>The advantage is that you can use emacs (or other sophisticated
>editors) to go to a function in a familiar way that you were used
>to in other languages too.

For a long time, I thought that etags.fs is sufficient and we do not
need to add LOCATE to Gforth, but once we implemented LOCATE, I found
that I use it much more often than M-. (forth-find-tag).

>For those not familiar with ctags, in additions to definitions
>it finds also references. It also is blindingly fast.
>Under 100 mS for hundreds of files.

So you may be claiming that ctags covers the job of the where table.
I do not see how to achive that.  ctags has an option --cxref, but it
just outputs the definitions in a different format.  E.g., when I say

ctags --lang=forth --cxref *.fs

it shows:

...
disjoint?        187 gray.fs          : disjoint?
empty            105 gray.fs          : empty
...

which shows the definitions of these words, but not the uses.  And it
also does not show the uses of DUP.  By contrast, if I include
gray.fs, and then say WHERE DUP, I get the following:

[... 1128 lines of DUP uses in other files ...]
gray.fs:85:2: dup @ = ;                                                     1128
gray.fs:88:2: dup ! ;                                                       1129
gray.fs:112:2: dup cells/set !                                              1130
gray.fs:120:3: dup @ ,                                                      1131
gray.fs:295:18: source-location dup 2@ swap cr type                         1132
gray.fs:354:2: dup follow-set @ subset? 0=  \ would everything stay the same1133
gray.fs:357:22: follow-set @ union dup follow-set !                         1134
gray.fs:385:2: dup pass2                                                    1135
gray.fs:460:19: operand1 compute dup if                                     1136
gray.fs:499:2: dup operand1 propagate                                       1137

with the DUP use being highlighted.  The where table, which consumes
quite a bit of memory (827_776 bytes in gforth.fi for a 64-bit
system), contains that information.  I do not see anything in the
ctags/etags manual that provides this functionality.  So the LOCATE
information (a cell for each dictionary entry) may be seen as
duplicate information, but the WHERE information does not duplicate
anything.

>>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:
>
>This was exactly my point.

Your point was that Gforth uses 6 cells for a word with a name that
fits in a cell and where the body takes one cell?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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