I've been dusting-off fig-Forth for VAX-11 and noticed that every word
in the dictionary has 128 added to the character code of the last
character in the word name. Everything seems to work except a few things
like VLIST (prints a list of defined words like WORDS in ANS Forth)
printing a garbage character at the end of each word.

I wrote my own version of VLIST to unmunge the last characters, but it's
hard to believe it's been messed up for 40 years. Is there some
peculiarity in fig-Forth or the VAX-11 (I'm using significantly later
hardware and OS) that made this work correctly back in the day?

--
David Meyer
Takarazuka, Japan
papa@sdf.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/25 8:35 AM, David Meyer wrote:

I've been dusting-off fig-Forth for VAX-11 and noticed that every word
in the dictionary has 128 added to the character code of the last
character in the word name. Everything seems to work except a few things
like VLIST (prints a list of defined words like WORDS in ANS Forth)
printing a garbage character at the end of each word.

I wrote my own version of VLIST to unmunge the last characters, but it's
hard to believe it's been messed up for 40 years. Is there some
peculiarity in fig-Forth or the VAX-11 (I'm using significantly later hardware and OS) that made this work correctly back in the day?

Checking a handy fig-Forth implementation, I see that EMIT clears that
bit...

--
http://davesrocketworks.com
David Schultz
"The cheeper the crook, the gaudier the patter." - Sam Spade

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Meyer <papa@sdf.org> writes:

I've been dusting-off fig-Forth for VAX-11 and noticed that every word
in the dictionary has 128 added to the character code of the last
character in the word name.

...

Is there some
peculiarity in fig-Forth or the VAX-11 (I'm using significantly later >hardware and OS) that made this work correctly back in the day?

David Schultz gave the answer to why VLIST works in fig-Forth.

Here's the reason why the last bit is set: Fig-Forth has "variable
length names" as headline feature, whereas earlier Forth systems only
stored the length and 3 characters (i.e., VLIST would output its own
name as VLI__ or so), and would match/conflict with, e.g., VLIKE.

But unlike modern systems, fig-Forth does not always store the full
length of the name. Instead, you could set the length of the number
of characters to be stored by setting a variable. That variable can
change from one definition to the next, so you do not know from this
variable how many characters are stored for a particular name.
Instead, you know the last stored character by looking whether the
most significant bit is set (the most significant bit of the
count+flags byte is also set to allow finding it from the other end.

- 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 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/25 11:18 AM, Anton Ertl wrote:

Here's the reason why the last bit is set: Fig-Forth has "variable
length names" as headline feature, whereas earlier Forth systems only
stored the length and 3 characters (i.e., VLIST would output its own
name as VLI__ or so), and would match/conflict with, e.g., VLIKE.

Way back when I bought copies of the fig listings, I also bought a copy

of the Glossary, Model, and Editor document. Which had little details
like this.

Plus of course the 6502 model implementation (in Forth) including an
EMIT that has "7F # AND,"

Later you could get things like the Systems Guide to fig-Forth.

All available online these days of course. For free. Sigh.

--
http://davesrocketworks.com
David Schultz
"The cheeper the crook, the gaudier the patter." - Sam Spade

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It occurred to me that another factor in this is that the VAX-11 OS used
7-bit ASCII as its character set, so perhaps terminals and printers of
that time would just print the character indicated by the lower 7 bits
of each byte they were sent, ignoring the high bit. So I am seeing
munged characters because I'm using equipment that looks at all 8 bits
for character codes?
--
David Meyer
Takarazuka, Japan
papa@sdf.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxf <dxforth@gmail.com> writes:

Ideally FigForth should allow 8-bit EMITs and ID. rewritten to use a
127 AND EMIT loop instead of TYPE .

That works. VLIST using the new ID. prints the list of words unmunged as expected.

--
David Meyer
Takarazuka, Japan
papa@sdf.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2025Apr16.181856@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

David Meyer <papa@sdf.org> writes:

I've been dusting-off fig-Forth for VAX-11 and noticed that every word
in the dictionary has 128 added to the character code of the last
character in the word name.

...

Is there some
peculiarity in fig-Forth or the VAX-11 (I'm using significantly later >>hardware and OS) that made this work correctly back in the day?

David Schultz gave the answer to why VLIST works in fig-Forth.

Here's the reason why the last bit is set: Fig-Forth has "variable
length names" as headline feature, whereas earlier Forth systems only
stored the length and 3 characters (i.e., VLIST would output its own
name as VLI__ or so), and would match/conflict with, e.g., VLIKE.

But unlike modern systems, fig-Forth does not always store the full
length of the name. Instead, you could set the length of the number
of characters to be stored by setting a variable. That variable can
change from one definition to the next, so you do not know from this
variable how many characters are stored for a particular name.
Instead, you know the last stored character by looking whether the
most significant bit is set (the most significant bit of the
count+flags byte is also set to allow finding it from the other end.

This allowed to define $.... as a word, storing the length (5) and
only one letter of the name.
So any word like $1AC4 matches, and $ could try to find out what
number was meant. $QQQQ gives an error. So you could have a
hex number without changing BASE.

This is similar to PREFIX in ciforth:
: $ (NUMBER) .... ; PREFIX IMMEDIATE
The difference is that the name of $ matches any word that commences
with $ , e.g. $1AC4 and $QQQQRRRR , governed by a bit in the flag field
of $.
The prefix has the responsability to advance the parse pointer (aka >IN)
unlike in fig-Forth. The parse pointer was left immediately behind $.
PREFIXes can handle arbitrary length and strings containing blank space.

- anton

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)