Put aside all my extensions and explored using FigForth core
words only. Here are three of several things I found interesting:

Fig-Forth 1.0.A
( Example #1, Stash data stack items)

: XX S0 @ SP! ; OK
: S0! S0 ! ; OK
: !S0 TIB @ S0! ; OK
: .S S0 @ BEGIN CELL - SP@ OVER < WHILE DUP ? REPEAT DROP ; OK

( some stack items.............) 1 2 3 4 5 OK
..s 1 2 3 4 5 OK
( stash them...................) sp@ s0! OK
( use the stack................) 666 777 888 OK
..s 666 777 888 OK
( restore stashed items........) xx !s0 OK
..s 1 2 3 4 5 OK

( Example #2, Input counted string _directly_ into given storage area)

: CREATE: <BUILDS DOES> ; OK
: := DP @ SWAP DP ! 1 WORD DP ! ; OK

CREATE: FOO 64 ALLOT ( storage area for counted string FOO) OK
FOO := Hello Chuck! OK
FOO COUNT CR TYPE
Hello Chuck! OK

( Example #3, Easily edit block screen without editor)

lib OK
0 60 (LINE) DROP 1024 BLANKS OK
0 60 (LINE) EXPECT ( FOO BAR ) OK
1 60 (LINE) EXPECT : FOO ." foo " ; OK
2 60 (LINE) EXPECT : BAR ." bar " ; OK
UPDATE FLUSH OK
60 LIST
SCR # 60
0 ( FOO BAR )
1 : FOO ." foo " ;
2 : BAR ." bar " ;
3
4
....
OK

( Note RETURNS entered after EXPECTs)

PS: Having initializing variables can be a nice fit:
CREATE: FCB 0 , HERE 64 ALLOT HERE 1024 ALLOT
CONSTANT FCB.BUF
CONSTANT FCB.NAME

PS2: Alignment after data is not needed when storage is followed
by a definition since Fig word names need not start on a
word boundary (in my build).

Nice to hear some new echoes from 'ole figForth'. IIRC my first exposure
to Forth was a fig-forth listing for the 6502 CPU.
Half the listing was printed on red paper to prevent copying.

Last contact I had was flipping through Ting's Guide booklet:
https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf

Opening it again, I enjoyed reading the preface to the 2nd edition:
Fig-Forth refuses to Die. :-)

On 4/04/2024 9:30 am, minforth wrote:
> Nice to hear some new echoes from 'ole figForth'. IIRC my first exposure
> to Forth was a fig-forth listing for the 6502 CPU.
> Half the listing was printed on red paper to prevent copying.

It wasn't Fig's intent that it should be copied?

> Last contact I had was flipping through Ting's Guide booklet:
> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf
>
> Opening it again, I enjoyed reading the preface to the 2nd edition:
> Fig-Forth refuses to Die.  :-)

"Let's do the [1978] Time Warp again

With a bit of a mind flip
You're into the time slip
And nothing can ever be the same
You're spaced out on sensation
Like you're under sedation"

Unlike 1994 which has been one long 'Thou shalt not'

minforth@gmx.net (minforth) writes:
> Last contact I had was flipping through Ting's Guide booklet:
> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf

This looks good and I'll try to read through it. Inside F83 is also
excellent. I looked at a listing of FigForth a while back and found it
incomprehensible, but maybe the pdf above will help. It would be
interesting to run it under simulation and track the stack activity.

On 4/04/2024 12:17 pm, Paul Rubin wrote:
> minforth@gmx.net (minforth) writes:
>> Last contact I had was flipping through Ting's Guide booklet:
>> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf
>
> This looks good and I'll try to read through it. Inside F83 is also
> excellent. I looked at a listing of FigForth a while back and found it
> incomprehensible, but maybe the pdf above will help. It would be
> interesting to run it under simulation and track the stack activity.

Another in-depth description of fig-forth is here:

https://archive.org/details/MitchDerickLindaBakerForthEncyclopediaTheCompleteForthProgrammersManualMountainViewPress1982

Discovered it in the engineering library of the organization where I worked.
It was as if the heavens had opened.

On 4/3/24 8:17 PM, Paul Rubin wrote:
> minforth@gmx.net (minforth) writes:
>> Last contact I had was flipping through Ting's Guide booklet:
>> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf
>
> This looks good and I'll try to read through it. Inside F83 is also
> excellent. I looked at a listing of FigForth a while back and found it
> incomprehensible, but maybe the pdf above will help. It would be
> interesting to run it under simulation and track the stack activity.

There are two ways to look at the Fig-Forth source. The first is in the
partially predigested assembly source for a particular processor. As
easy to follow as an eForth listing. :-)

The second is the high level source suitable for a meta-compiler.
Published in one of the fig documents. The Installation Manual I think.

--
http://davesrocketworks.com
David Schultz

dxf wrote:

> On 4/04/2024 9:30 am, minforth wrote:
>> Nice to hear some new echoes from 'ole figForth'. IIRC my first exposure
>> to Forth was a fig-forth listing for the 6502 CPU.
>> Half the listing was printed on red paper to prevent copying.

> It wasn't Fig's intent that it should be copied?

Even back then there were people who made money from publicly available documents. ;-)

To be fair, the web hadn't been invented yet, so you had to buy printed versions

In article <36e3cd8ce77bf333bfc0ba83d126ae1c@www.novabbs.com>,
minforth <minforth@gmx.net> wrote:
>Nice to hear some new echoes from 'ole figForth'. IIRC my first exposure
>to Forth was a fig-forth listing for the 6502 CPU.
>Half the listing was printed on red paper to prevent copying.

I have the original Apple 6502 bought from FIG in the 80's.
Only the cover page was colored so that you can keep them apart.
My 8080 copy was yellow and ass eared.
The public domain message is printed on the cover page and the
first page of the document.

>
>Last contact I had was flipping through Ting's Guide booklet:
>https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf
>
>Opening it again, I enjoyed reading the preface to the 2nd edition:
>Fig-Forth refuses to Die. :-)
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

Paul Rubin <no.email@nospam.invalid> writes:
>minforth@gmx.net (minforth) writes:
>> Last contact I had was flipping through Ting's Guide booklet:
>> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf
>
>This looks good and I'll try to read through it. Inside F83 is also
>excellent.

One interesting aspect is that Ting organized the two guides quite
differently. Apparently he was not happy with the organization of
System's Guide to fig-Forth.

>I looked at a listing of FigForth a while back and found it
>incomprehensible, but maybe the pdf above will help.

It certainly should, particularly because the guide shows Forth source
code rather than the assembler input that the listings contained.

- 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: https://euro.theforth.net/2023

Paul Rubin wrote:

> minforth@gmx.net (minforth) writes:
>> Last contact I had was flipping through Ting's Guide booklet:
>> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf

> This looks good and I'll try to read through it. Inside F83 is also
> excellent. I looked at a listing of FigForth a while back and found it
> incomprehensible, but maybe the pdf above will help. It would be
> interesting to run it under simulation and track the stack activity.

Beware of the subtle differences to later standards. E.g. with DO-LOOPs:
in figForth, LEAVE only sets the current index to the final value, the
innermost loop is not exited until the next LOOP.

Historical anecdote, but even then, the DO-LOOP construct was rather
impractical.

On Thu, 4 Apr 2024 12:34:22 +1100
dxf <dxforth@gmail.com> wrote:

> Another in-depth description of fig-forth is here:
>
> https://archive.org/details/MitchDerickLindaBakerForthEncyclopediaTheCompleteForthProgrammersManualMountainViewPress1982

Larger print to read, and download option here:
https://epdf.tips/forth-encyclopedia-the-complete-forth-programmers-manual.html

In article <2024Apr4.102631@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>minforth@gmx.net (minforth) writes:
>>> Last contact I had was flipping through Ting's Guide booklet:
>>> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf
>>
>>This looks good and I'll try to read through it. Inside F83 is also
>>excellent.
>
>One interesting aspect is that Ting organized the two guides quite
>differently. Apparently he was not happy with the organization of
>System's Guide to fig-Forth.
>
>>I looked at a listing of FigForth a while back and found it
>>incomprehensible, but maybe the pdf above will help.
>
>It certainly should, particularly because the guide shows Forth source
>code rather than the assembler input that the listings contained.

The assembler listing is one to one to Forth source, so it is
in first approximation equally worthless. What was the last time
a gforth user looked up the source of DROP ? Was it illuminating?

You need the glossary and the installation guide.
https://home.hccnet.nl/a.w.m.van.der.horst/figforth.html
The fig listings were intended to type in (before modems, let
alone internet) not to be studied.
>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

albert@spenarnc.xs4all.nl writes:
>The assembler listing is one to one to Forth source

Certainly not. E.g., the Forth source as presented by Ting contains
documentation, the assembler listing does not. E.g., here is the
definition of COUNT in both forms:

First, the source code as presented by Ting:

: COUNT addrl -- addr2 n
DUP 1+ addr2=addrl+l
SWAP Swap addrl over addr2 and
C@ fetch the byte count to the stack.
;

DB 85H ; COUNT
DB 'COUN'
DB 'T'+80H
DW DOES-8
COUNT DW DOCOL
DW DUP
DW ONEP
DW SWAP
DW CAT
DW SEMIS

>What was the last time
>a gforth user looked up the source of DROP ? Was it illuminating?

Good question. DROP is written in Vmgen, not in Forth, so others may
not find it illuminating. For words written in Forth, things may be
different. Try:

locate if
see if
simple-see if
see-code if

>The fig listings were intended to type in (before modems, let
>alone internet) not to be studied.

Exactly. By contrast, System's Guide to fig-Forth is intended to be
studied.

- 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: https://euro.theforth.net/2023

David Schultz <david.schultz@earthlink.net> writes:
> There are two ways to look at the Fig-Forth source. The first is in
> the partially predigested assembly source for a particular
> processor. As easy to follow as an eForth listing. :-)

Not sure if that was ironic, but I found eforth and the fig assembler
listings relatively easy to follow, though it was obvious that the asm
code had been generated by another program and then maybe massaged a
little. It was the Forth source that I found near unreadable.

On 4/4/24 12:33 PM, Paul Rubin wrote:

> Not sure if that was ironic, but I found eforth and the fig assembler
> listings relatively easy to follow, though it was obvious that the asm
> code had been generated by another program and then maybe massaged a
> little. It was the Forth source that I found near unreadable.

Considering that it was written in a time before full screen editors and
most likely with an ASR33, give it a break.

--
http://davesrocketworks.com
David Schultz

David Schultz <david.schultz@earthlink.net> writes:
> Considering that it was written in a time before full screen editors
> and most likely with an ASR33, give it a break.

I don't see how that would be an issue? Spitbol is pretty readable and
it was originally written in IBM 360 assembly language, and probably
keypunched. It is heavily commented though. FigForth and cmForth were
pretty unreadable to me, I think, partly from lack of code comments, but
also partly because of Forth itself.

On 5/04/2024 11:25 am, Paul Rubin wrote:
> David Schultz <david.schultz@earthlink.net> writes:
>> Considering that it was written in a time before full screen editors
>> and most likely with an ASR33, give it a break.
>
> I don't see how that would be an issue? Spitbol is pretty readable and
> it was originally written in IBM 360 assembly language, and probably
> keypunched. It is heavily commented though. FigForth and cmForth were
> pretty unreadable to me, I think, partly from lack of code comments, but
> also partly because of Forth itself.

Having decided one doesn't need or want forth, there's little incentive
to become fluent in it. I could say C is unreadable - to me. When I'm
developing an algorithm, the pseudo-code is largely forth - that's how
ingrained the latter has become.

Paul Rubin <no.email@nospam.invalid> writes:
>FigForth and cmForth were
>pretty unreadable to me, I think, partly from lack of code comments, but
>also partly because of Forth itself.

Are you sure you did not read a mutilated version of cmForth that was
stripped of the shadow screens? cmForth has lots of comments in the
shadow screens, and there is a nice version that integrates the
screens and shadow screens into one text file:

<https://github.com/ForthHub/cmFORTH/blob/combined/cmforth.fth>

The uses of magic numbers in the source screens is not so great, though.

"System's Guide to fig-Forth" also contains lots of comments, but more
importantly, Ting presents the code as illustration of the explanatory
text he writes.

However, it does not seem to be the actual source code, as evidenced
by the fact that he distributes [COMPILE] <word> across lines in most
places, and that does not work in source code.

What uncommented fig-Forth source code have you looked at? I found

https://github.com/ForthHub/FIG-Forth/blob/master/fig.fth

which contains comments, and there is also a glossary:

https://github.com/ForthHub/FIG-Forth/blob/master/glossary.txt

- 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: https://euro.theforth.net/2023

For exploration, lots of info also here:
https://www.forth.org/fig-forth/contents.html

In article <phadndBg9Oy7lZP7nZ2dnZfqnPSdnZ2d@earthlink.com>,
David Schultz <david.schultz@earthlink.net> wrote:
>On 4/3/24 8:17 PM, Paul Rubin wrote:
>> minforth@gmx.net (minforth) writes:
>>> Last contact I had was flipping through Ting's Guide booklet:
>>> https://www.forth.org/OffeteStore/1010_SystemsGuideToFigForth.pdf
>>
>> This looks good and I'll try to read through it. Inside F83 is also
>> excellent. I looked at a listing of FigForth a while back and found it
>> incomprehensible, but maybe the pdf above will help. It would be
>> interesting to run it under simulation and track the stack activity.
>
>There are two ways to look at the Fig-Forth source. The first is in the
>partially predigested assembly source for a particular processor. As
>easy to follow as an eForth listing. :-)
>
>The second is the high level source suitable for a meta-compiler.
>Published in one of the fig documents. The Installation Manual I think.

At this time a meta-compiler was worthless, because you need
access to a Forth compiler in the first place. It is not present
in the Installation manual. A typical situation was that I lent
the fig z80 assembler source print to a collega who had also an
Osborne (CP/M) computer. He typed it in over the weekend.
There was no need to understand it, merely a Z80 assembler.

As far as I remember a metacompiler was present in screens printed in
one of the FIG implementations. There was pressure that
the only way to bring up a Forth system was through
a meta compiler.

Nowadays I guess it is, in order of importance, C-source,
metacompiler, assembler source, other languages.

>David Schultz
>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

albert@spenarnc.xs4all.nl writes:
> Nowadays I guess it is, in order of importance, C-source,
> metacompiler, assembler source, other languages.

These days there are plenty of computers and language implementations
available, so if you're trying to write a Forth, it seems reasonable to
metacompile starting with some existing Forth such as gforth.

This is also fun: https://github.com/nineties/planckforth

On 5/04/2024 9:13 pm, Paul Rubin wrote:
> albert@spenarnc.xs4all.nl writes:
>> Nowadays I guess it is, in order of importance, C-source,
>> metacompiler, assembler source, other languages.
>
> These days there are plenty of computers and language implementations
> available, so if you're trying to write a Forth, it seems reasonable to
> metacompile starting with some existing Forth such as gforth.

I thought of using the F83 metacompiler and it sent me packing.

In article <87bk6o2k3r.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>albert@spenarnc.xs4all.nl writes:
>> Nowadays I guess it is, in order of importance, C-source,
>> metacompiler, assembler source, other languages.
>
>These days there are plenty of computers and language implementations
>available, so if you're trying to write a Forth, it seems reasonable to
>metacompile starting with some existing Forth such as gforth.

Not so reasonable as it seems. The differences between metacompilers
is greater than between assemblers. Surprisingly, assemblers are
actually documented, often in great detail.
Of course you use your own metacompiler, virtually useless for
other people.
The noforth msp430 family is generated by the same metacompiler.
There is a separate metacompiler for the riscv noforth, and for the
pico (arm) noforth.
At least we are avoiding assembler code?
No way. Not only are there three assembler languages for msp430,
riscv and arm, you have to invent the language, and then have
to write an assembler for it.

Supposedly these metacompilers are ISO/portable and I'm busy
to run them on ciforth. Porting from WIN32FORTH to gforth
was comparitively easy, by no means effortless.
In ciforth it isn't that easy, because this is a simple Forth that
doesn't contains the proverbial kitchen sinks. You would be surprised
how much conventions are violated by an unconventional Forth.

Then the real kicker. How good are meta compilers documented?
On a scale of one to ten how complicated is a meta-compiler?
In reality I'm at a loss when I encounter a problem in the
meta-compiler, and resort to consulting the authors.
Compare that to debugging an assembler program where tools
are available since the stone age. At least you are debugging
the Forth itself.

>This is also fun: https://github.com/nineties/planckforth
Or this:
https://dacvs.neocities.org/SF/
a forth using a single tool, xxd, conversion to hex code to executables,
hand assembling instructions.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

Everything is rather easy as long as you are within the desktop/PC world.

But the Forth system itself is only the second half part of the story.
For MCUs or embedded devices you have the OEM tool set and probably
I/O drivers, for (some of) which you have to write Forth wrapper words.
IOW there is not much choice.