FIG Forth vs F83 vs Polyforth

[Paul Rubin]

I think these were all in use in around the same era, and on about the
same hardware.

Could they be said to have been competing with each other, or did they
address mostly non-overlapping audiences?

Can anyone describe how they compared with each other? Features,
performance, or whatever else would matter to a user or developer.

I'm asking this from historical interest and with the idea that it might
help understand Forth a little better. By now I hope there are no
lingering flame wars related to the topic.

Thanks ;).

[hughag...@gmail.com]

UR/Forth from LMI was the primary Forth system for professional use.
I bench-marked it on recursive-descent programs that took about an hour,
and I found it to be the same speed as Turbo-C (Small memory-model).
The available memory was also about the same.

FIGforth, F83 and PolyForth were all ITC systems that were quite
slow on the x86. They also all suffered from extreme memory shortage
because they didn't take advantage of the x86 segmented-memory
(they were all direct ports of MicroForth that was 64KB total).
I'm not aware of any of these being used professionally.
F83 (free) was the most popular for hobbyist use (FIGforth was free
and PolyForth cost a lot of money, but neither were as good as F83).
I also used TCOM that was free and quite fast, but not interactive.

[dxf...@gmail.com]

If by "F83" you mean the implementation not the Standard, there would
have been very little competition between them. FIG stopped supporting
fig-Forth once there were enough forth users and switched to supporting
the Standards process instead.

Being a full-blown commercial product PolyForth was packed with features
and facilities no PD implementation could compete. The reference manual
can be found at GreenArrays:

http://www.greenarraychips.com/home/documents/downindex.html

All three were ITC based.

[sdwj...@gmail.com]

What Hugh says is fair. But don't be mislead. The concerns of the professional
is different from the general user. FigForth with DOS on PC was sweet; can't
fit a Fig in an 8049 but who cares. FigForth introduced many to Forth and
provided common ground for discussion. FigForth could be found on devices
coming out at the time such as ValForth (a Fig) on the Atari and Fig articles
were run in Forth publications. FigForth was small and easy to understand.
--
me

[hughag...@gmail.com]

FIG didn't stop supporting figForth due to any vague idea that
there were "enough Forth users" (whatever that means).

According to Jeff Fox, Elizabeth Rather wanted to sue FIG for
pirating MicroForth from Forth Inc. (FIG did pirate it).
Charles Moore made an agreement with FIG that they could continue
to distribute figForth so long as they agreed not to upgrade it.
They definitely had to agree to not pirate anything else.
This is why figForth stagnated --- it was still 1970s technology
well into the 1980s --- F83 became the new PD Forth for novices.
F83 was developed from scratch --- it wasn't pirated.
By that time, there were multiple Forth systems, some PD and
some commercial, all of which were developed from scratch.
As I said, UR/Forth (originally PC/Forth) from LMI was the best.
This is also why PolyForth stagnated --- it was still 1970s technology
well into the 1990s --- Charles Moore wasn't upgrading it anymore
because he had been kicked out of Forth Inc. by Elizabeth Rather.

According to Jeff Fox, the reason why Charles Moore left Forth Inc.
was that Elizabeth Rather wanted to sue FIG for pirating MicroForth
and sue everybody else who developed a Forth for stealing Forth Inc.'s
"look and feel" (similar to what Apple was doing in regard to GUI).
Charles Moore wanted to allow other people to develop Forth systems
in competition with Forth Inc. --- he felt confident that he could
develop better Forth systems because he was a better programmer.
Elizabeth Rather wasn't a programmer at all --- she just wanted
Forth Inc. to have sole ownership of Forth --- she wanted to use
lawsuits to prevent competition.
For her, Forth was the property of Forth Inc., just like a cow
is property, and she didn't want anybody to steal her cow.
This disagreement was irreconcilable --- they had to part company.
Elizabeth Rather's plan for hitting competitors with lawsuits flopped
because Charles Moore was the inventor of Forth, so she had no legal basis.
Her new plan for killing the Forth community was to develop the
ANS-Forth Standard that made everybody (especially UR/Forth) non-standard.
This plan worked pretty well --- ANS-Forth killed the Forth community.

Elizabeth Rather didn't understand that software technology can't
stagnate. Charles Moore's Forth was a winner in the 1970s, but it
couldn't just stagnate there forever. It had to be upgraded.
Charles Moore knew this, which is why he was okay with figForth
so long as it didn't get upgraded (he knew that it would soon be
non-competitive if he was upgrading the Forth Inc. product).
Elizabeth Rather still didn't understand this in 1994 ---
ANS-Forth was 1970s technology now written in stone so it couldn't
be upgraded. She still doesn't understand this ---
she endlessly promotes 1970s style programming without code-libraries.

This is essentially why the world sees Forth as stagnating in the
1970s, and Forth programmers as being too dumb to notice that we are
no longer living in the 1970s (not in the 20th century at all!).
Elizabeth Rather is a boat-anchor that holds the Forth community
down in the 1970s --- she needs to be jettisoned!

Killing the Forth community is also the plan with Forth-200x,
except that now MPE is a "major vendor" along with Forth Inc.
(Forth Inc. is fizzling out; eventually MPE will be the only "major vendor").

On Tuesday, December 19, 2017 at 4:44:15 PM UTC-7, Elizabeth D. Rather wrote:
> The major vendors are certainly necessary for a meaningful standard.
> FORTH, Inc. is committed to the process.

Essentially, Forth-200x means that only MPE and Forth Inc. can develop
Forth --- everybody else has to be a customer.

[hughag...@gmail.com]

On Sunday, April 28, 2019 at 7:58:03 PM UTC-7, sdwj...@gmail.com wrote:
> What Hugh says is fair. But don't be mislead. The concerns of the professional
> is different from the general user. FigForth with DOS on PC was sweet; can't
> fit a Fig in an 8049 but who cares. FigForth introduced many to Forth and
> provided common ground for discussion. FigForth could be found on devices
> coming out at the time such as ValForth (a Fig) on the Atari and Fig articles
> were run in Forth publications. FigForth was small and easy to understand.

Well, I also said that Charles Moore was okay with figForth:

On Sunday, April 28, 2019 at 8:05:45 PM UTC-7, hughag...@gmail.com wrote:
> Elizabeth Rather didn't understand that software technology can't
> stagnate. Charles Moore's Forth was a winner in the 1970s, but it
> couldn't just stagnate there forever. It had to be upgraded.
> Charles Moore knew this, which is why he was okay with figForth
> so long as it didn't get upgraded (he knew that it would soon be
> non-competitive if he was upgrading the Forth Inc. product).

I think Charles Moore was okay with figForth as an introduction into
Forth for people who wanted to try Forth but were not ready to spend money.
Forth is a lot different from C and Pascal, so selling Forth is difficult!
Potential customers need to get a feel for it first, before they commit
to spending money on it --- or commit to commercial products with it.
F83 and figForth were both "sweet" in that they gave the user the
Forth interactive environment and the meta-compiling, which were the two
fundamental features of Forth that distinguished Forth from C and Pascal.
F83 and figForth weren't really good enough for commercial products,
but after they were learned, an easy transition could be made to a
professional Forth system (the programmers were portable).
Similarly, Stephen Pelc is okay with gForth nowadays --- gForth is
non-competitive and always will be --- it is an introduction for newbies.
Stephen Pelc gets to introduce potential customers to Forth with gForth,
but he also avoids doing customer-support for gForth which is a hassle
(especially because newbies ask a lot of questions, which can get tiresome).

UR/Forth for MS-DOS was the first professional Forth system I used.
Prior to that, I had used HESforth (Vic-20), SuperForth (C64) and
ISYS Forth (Apple-IIc).
I never actually used figForth or F83, but I heard good things about
F83 --- I wasn't opposed to F83 --- it helps the Forth community.
To get a job as a Forth programmer though, UR/Forth experience was needed.
Being an F83 or PolyForth programmer wouldn't get you hired anywhere.

[dxf...@gmail.com]

On Monday, 29 April 2019 13:05:45 UTC+10, hughag...@gmail.com wrote:
> On Sunday, April 28, 2019 at 7:30:13 PM UTC-7, dxf...@gmail.com wrote:
> >
> > FIG stopped supporting
> > fig-Forth once there were enough forth users and switched to supporting
> > the Standards process instead.

> > ...

>
> FIG didn't stop supporting figForth due to any vague idea that
> there were "enough Forth users" (whatever that means).

I'm going by statements made by FIG in FD.

> According to Jeff Fox, Elizabeth Rather wanted to sue FIG for
> pirating MicroForth from Forth Inc. (FIG did pirate it).
> Charles Moore made an agreement with FIG that they could continue
> to distribute figForth so long as they agreed not to upgrade it.
> They definitely had to agree to not pirate anything else.
> This is why figForth stagnated --- it was still 1970s technology
> well into the 1980s --- F83 became the new PD Forth for novices.

Whatever agreement may have been made, it would have amounted to
tokenism as fig-Forth was already in the hands of vendors who
were fixing and upgrading it. FIG didn't need to sell listings
to survive as it now had paying subscribers and volunteers willing
to work for nothing.

> F83 was developed from scratch --- it wasn't pirated.

F83 was no less "pirated" than Ragsdale's 6502 forth which became
fig-Forth. Any IP that may have existed in fig-Forth was duplicated
in F83. F83 went one better and grabbed multi-tasking. If there
was any difference between fig-Forth and F83 it was the latter
wasn't sponsored by FIG who by then had ties to Forth Inc. with
Ragsdale a share-holder and director.

Paul's comment about flame-wars appears to have been somewhat premature :)

[minf...@arcor.de]

Having used both in their time I can't remember but friendly eagerness or
even technical enthusiasm. Technical journals published interesting Forth
articles regularly. You chose whatever you had in your hands and fit to
your board, and then modified it by hacking.

IOW there was no real choice like today where you can download source code
from the web for free. OTOH there were many more engineering companies offering
professional Forth support than today.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>I think these were all in use in around the same era, and on about the
>same hardware.

fig-Forth was written in 1978, with ports done in 1979 and 1980. It
obviously did not comply with Forth-79 nor Forth-83. It was available
on many different processors.

F83 was written in 1983 to comply with Forth-83 and was available on
the 8086.

>Could they be said to have been competing with each other, or did they
>address mostly non-overlapping audiences?

Mostly non-overlapping. PolyForth was commercial, and addresses
customers who wanted commercial support. F83 was for 8086 users after
1983. fig-Forth was for the rest.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2018: http://www.euroforth.org/ef18/

[Elizabeth D. Rather]

On 4/28/19 6:36 PM, dxf...@gmail.com wrote:
> On Monday, 29 April 2019 13:05:45 UTC+10, hughag...@gmail.com wrote:
>> On Sunday, April 28, 2019 at 7:30:13 PM UTC-7, dxf...@gmail.com wrote:
>>>
>>> FIG stopped supporting
>>> fig-Forth once there were enough forth users and switched to supporting
>>> the Standards process instead.
>>> ...
>>
>> FIG didn't stop supporting figForth due to any vague idea that
>> there were "enough Forth users" (whatever that means).
>
> I'm going by statements made by FIG in FD.
>
>> According to Jeff Fox, Elizabeth Rather wanted to sue FIG for
>> pirating MicroForth from Forth Inc. (FIG did pirate it).
>> Charles Moore made an agreement with FIG that they could continue
>> to distribute figForth so long as they agreed not to upgrade it.
>> They definitely had to agree to not pirate anything else.
>> This is why figForth stagnated --- it was still 1970s technology
>> well into the 1980s --- F83 became the new PD Forth for novices.
>
> Whatever agreement may have been made, it would have amounted to
> tokenism as fig-Forth was already in the hands of vendors who
> were fixing and upgrading it. FIG didn't need to sell listings
> to survive as it now had paying subscribers and volunteers willing
> to work for nothing.
>
>> F83 was developed from scratch --- it wasn't pirated.

According to Don Colburn, who first became involed at this time,
Ragsdale approached FORTH, Inc. to make a 6502 Forth, and they declined.
So, Ragsdale engaged Maj. Robert Selzer, who had used microFORTH for an
AMI 6800 development system on an Army project and was privately
developing a standalone editor/assembler/linker package for the 6502.
Selzer wrote a 6502 Forth assembler, and used the Army’s microFORTH
metacompiler to target compile the first 6502 stand-alone Forth for the
Jolt single board computer. Modifications to this model led to the first
FIG Forth. See the published paper, The Evolution of Forth, written by
Chuck, myself, and Don:
https://www.forth.com/resources/forth-programming-language/

> F83 was no less "pirated" than Ragsdale's 6502 forth which became
> fig-Forth. Any IP that may have existed in fig-Forth was duplicated
> in F83. F83 went one better and grabbed multi-tasking. If there
> was any difference between fig-Forth and F83 it was the latter
> wasn't sponsored by FIG who by then had ties to Forth Inc. with
> Ragsdale a share-holder and director.

F83 was developed at a time when FORTH, Inc. was in some financial
difficulty and the developers, some of whom had been deeply involved in
polyFORTH development, wanted to preserve some of that technology
(mainly the multitasker) in case it went under. FORTH, Inc. considered
going after them, and decided not to. But polyFORTH was substantially
faster than F83.

Cheers,
Elizabeth

--
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA

[a...@littlepinkcloud.invalid]

Elizabeth D. Rather <era...@forth.com> wrote:

> According to Don Colburn, who first became involed at this time,
> Ragsdale approached FORTH, Inc. to make a 6502 Forth, and they
> declined. So, Ragsdale engaged Maj. Robert Selzer, who had used
> microFORTH for an AMI 6800 development system on an Army project and
> was privately developing a standalone editor/assembler/linker
> package for the 6502. Selzer wrote a 6502 Forth assembler,

One small correction: the 6502 assembler was by Ragsdale. See
http://www.forth.org/fd/FD-V03N5.pdf

> and used the Army’s microFORTH metacompiler to target compile the
> first 6502 stand-alone Forth for the Jolt single board
> computer. Modifications to this model led to the first FIG
> Forth. See the published paper, The Evolution of Forth, written by
> Chuck, myself, and Don:
> https://www.forth.com/resources/forth-programming-language/
>

> F83 was developed at a time when FORTH, Inc. was in some financial
> difficulty and the developers, some of whom had been deeply involved
> in polyFORTH development, wanted to preserve some of that technology
> (mainly the multitasker) in case it went under. FORTH,
> Inc. considered going after them, and decided not to.

I didn't know that! Thanks.

> But polyFORTH was substantially faster than F83.

Indeed it was.

Andrew.

[dxf...@gmail.com]

I was sceptical given both were ITC but the following appears
to confirm. I can only assume F83's 8086 primitives weren't
as optimized as they might have been.

Integer benchmark 500 loops

F83 42s
PolyForth 13s
DX-Forth (DTC) 13s

Tested with PF86 ISD4 and F83 v2.1.0 executed under
DOSBOX (cycles=fixed 50000). Benchmark from
https://theultimatebenchmark.org/

32000 CONSTANT INTMAX

VARIABLE INTRESULT

: DOINT
1 DUP INTRESULT DUP >R !
BEGIN DUP INTMAX < WHILE
DUP NEGATE R@ +! 1+
DUP R@ +! 1+
R@ @ OVER * R@ ! 1+
R@ @ OVER / R@ ! 1+
REPEAT R> DROP DROP ;

: TEST ( n) 0 DO DOINT LOOP ;

[Anton Ertl]

dxf...@gmail.com writes:
>I was sceptical given both were ITC but the following appears
>to confirm. I can only assume F83's 8086 primitives weren't
>as optimized as they might have been.
>
>Integer benchmark 500 loops
>
>F83 42s
>PolyForth 13s
>DX-Forth (DTC) 13s

Makes me wonder how the alleged piracy worked. Did they hold up the
Forth, Inc. ship, take its treasures, and then reworked these
treasures for slowness?

>Tested with PF86 ISD4 and F83 v2.1.0 executed under
>DOSBOX (cycles=fixed 50000).

I don't know how DOSBOX reflects the speed of the actual CPU. Looking
at the source code of F83, I see several things that are not that slow
on the 8088, but slow down CPUs since the Pentium Pro a lot:

1) All primitives jump to a shared NEXT. Indirect branch prediction
suffers, although history-based indirect branch predictors on CPUs in
the last decade helps again.

2) It does not keep the TOS in a register. This means that a word
like 1+ introduces a 6-cycle latency (on recent CPUs) in computing the
TOS, while keeping TOS in a register would result in a 1-cycle
latency. F83 uses POP and PUSH for that, and the CPUs have some
optimizations of that, but IIRC only to avoid dependencies through SP,
not those of the memory accesses coming from these words.

3) There are also other things that are ok on the 8088, and are not
the fastest on recent CPUs (although probably minor fish):

LABEL >NEXT AX LODS AX W MOV 0 [W] JMP

ASSEMBLER LABEL NEST
W INC W INC RP DEC RP DEC IP 0 [RP] MOV W IP MOV
NEXT

LODS costs a bit more than a sequence of simple instructions on CPUs
since at least the 486. Two INCs or two DECs have a longer latency on
recent CPUs than 2 <reg> ADD.

>Benchmark from
>https://theultimatebenchmark.org/
>
>32000 CONSTANT INTMAX
>
>VARIABLE INTRESULT
>
>: DOINT
> 1 DUP INTRESULT DUP >R !
> BEGIN DUP INTMAX < WHILE
> DUP NEGATE R@ +! 1+
> DUP R@ +! 1+
> R@ @ OVER * R@ ! 1+
> R@ @ OVER / R@ ! 1+
> REPEAT R> DROP DROP ;

Most of the words in the loop are primitives in F83, except * (a short
colon definition) and /. / is a long colon definition in F83:

: ?NEGATE (S n1 n2 -- n3 ) 0< IF NEGATE THEN ;
: M/MOD (S d# n1 -- rem quot )
?DUP
IF DUP >R 2DUP XOR >R >R DABS R@ ABS UM/MOD
SWAP R> ?NEGATE
SWAP R> 0< IF NEGATE OVER IF 1- R@ ROT - SWAP THEN THEN
R> DROP
THEN ;
: /MOD (S n1 n2 -- rem quot ) >R S>D R> M/MOD ;
: / (S n1 n2 -- quot ) /MOD NIP ;

The call to / may cause a similar number of primitive calls than the
rest of the benchmark. And it looks like it is implementing floored
based on symmetric based on unsigned division. If polyForth
implements / as a primitive, this could explain quite a bit of the
performance difference.

[a...@littlepinkcloud.invalid]

dxf...@gmail.com wrote:
> On Monday, 29 April 2019 19:55:46 UTC+10, a...@littlepinkcloud.invalid wrote:
>> Elizabeth D. Rather <era...@forth.com> wrote:
>>
>> > But polyFORTH was substantially faster than F83.
>>
>> Indeed it was.
>

> I was sceptical given both were ITC but the following appears
> to confirm. I can only assume F83's 8086 primitives weren't
> as optimized as they might have been.

That's right. There wasn't much time spent on F83's primitives, and
there weren't all that many of them.

Andrew.

[none albert]

In article <V6ydncuL3vEB3lXB...@supernews.com>,

Reminds me, I need to spend the time saved on the ciforth's
primitives on the ciforth optimiser.

As Anton has pointed out the test of F83 versus polyforth is probably
a distortion. A proper test is to be executed on a genuine IBM pc
on a realistic mix of Forth programs.
>
>Andrew.
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[a...@littlepinkcloud.invalid]

albert <albert@cherry.(none)> wrote:
> In article <V6ydncuL3vEB3lXB...@supernews.com>,
> <a...@littlepinkcloud.invalid> wrote:
>>dxf...@gmail.com wrote:
>>> On Monday, 29 April 2019 19:55:46 UTC+10, a...@littlepinkcloud.invalid wrote:
>>>> Elizabeth D. Rather <era...@forth.com> wrote:
>>>>
>>>> > But polyFORTH was substantially faster than F83.
>>>>
>>>> Indeed it was.
>>>
>>> I was sceptical given both were ITC but the following appears
>>> to confirm. I can only assume F83's 8086 primitives weren't
>>> as optimized as they might have been.
>>
>>That's right. There wasn't much time spent on F83's primitives, and
>>there weren't all that many of them.
>
> Reminds me, I need to spend the time saved on the ciforth's
> primitives on the ciforth optimiser.
>
> As Anton has pointed out the test of F83 versus polyforth is probably
> a distortion. A proper test is to be executed on a genuine IBM pc
> on a realistic mix of Forth programs.

Absolutely. From what I remember it wasn't a huge difference, but it
was significant. Of course, you'd have to run it on contemporary
hardware for the measurements to mean anything.

Andrew.

[Paul Rubin]

a...@littlepinkcloud.invalid writes:
>> A proper test is to be executed on a genuine IBM pc on a realistic
>> mix of Forth programs.
>
> Absolutely. From what I remember it wasn't a huge difference, but it
> was significant. Of course, you'd have to run it on contemporary
> hardware for the measurements to mean anything.

To really mean anything you'd have to use contemporary software as well ;-).
But yeah the benchmark is more meaningful on period hardware.

I have an 80c88 laptop in a storage locker that I used a lot back in the
day. I might drag it out sometime and see if it still works.

Anyone know if Bochs is still a thing, and if it attempts cycle-accurate
simulation?

[dxf...@gmail.com]

On Tuesday, 30 April 2019 22:08:01 UTC+10, Anton Ertl wrote:
> ...

> Most of the words in the loop are primitives in F83, except * (a short
> colon definition) and /. / is a long colon definition in F83:
>
> : ?NEGATE (S n1 n2 -- n3 ) 0< IF NEGATE THEN ;
> : M/MOD (S d# n1 -- rem quot )
> ?DUP
> IF DUP >R 2DUP XOR >R >R DABS R@ ABS UM/MOD
> SWAP R> ?NEGATE
> SWAP R> 0< IF NEGATE OVER IF 1- R@ ROT - SWAP THEN THEN
> R> DROP
> THEN ;
> : /MOD (S n1 n2 -- rem quot ) >R S>D R> M/MOD ;
> : / (S n1 n2 -- quot ) /MOD NIP ;
>
> The call to / may cause a similar number of primitive calls than the
> rest of the benchmark. And it looks like it is implementing floored
> based on symmetric based on unsigned division. If polyForth
> implements / as a primitive, this could explain quite a bit of the
> performance difference.

Yes. In fact it was / that accounts for much of the slowness in this
benchmark on F83. Replacing it with code produced a more reasonable
18 sec. OTOH the original / avoids the hardware divide-zero trap. If
nothing else it's a good example of how *not* to implement division in
forth if speed is a consideration.

[dxf...@gmail.com]

On Wednesday, 1 May 2019 02:11:44 UTC+10, none albert wrote:
> ...

> As Anton has pointed out the test of F83 versus polyforth is probably
> a distortion. A proper test is to be executed on a genuine IBM pc
> on a realistic mix of Forth programs.

Rescuing my Pentium 200/Win98 machine before it went to tip I
re-ran the tests:

500 loops

F83 181s
F83 (code /) 78s
PolyForth 63s
DX-Forth (DTC) 20s

I was surprised at the last result but perhaps there's
something else going on.

[a...@littlepinkcloud.invalid]

Paul Rubin <no.e...@nospam.invalid> wrote:
> a...@littlepinkcloud.invalid writes:
>>> A proper test is to be executed on a genuine IBM pc on a realistic
>>> mix of Forth programs.
>>
>> Absolutely. From what I remember it wasn't a huge difference, but it
>> was significant. Of course, you'd have to run it on contemporary
>> hardware for the measurements to mean anything.
>
> To really mean anything you'd have to use contemporary software as
> well ;-).

Point taken!

> But yeah the benchmark is more meaningful on period hardware.

Much. All of the rules for "efficient coding" on x86 hardware seem to
have changed since then.

Andrew.

[hughag...@gmail.com]

This is what I said:

On Sunday, April 28, 2019 at 8:05:45 PM UTC-7, hughag...@gmail.com wrote:

> FIG didn't stop supporting figForth due to any vague idea that
> there were "enough Forth users" (whatever that means).
>
> According to Jeff Fox, Elizabeth Rather wanted to sue FIG for
> pirating MicroForth from Forth Inc. (FIG did pirate it).
> Charles Moore made an agreement with FIG that they could continue
> to distribute figForth so long as they agreed not to upgrade it.
> They definitely had to agree to not pirate anything else.
> This is why figForth stagnated --- it was still 1970s technology
> well into the 1980s --- F83 became the new PD Forth for novices.
> F83 was developed from scratch --- it wasn't pirated.
> By that time, there were multiple Forth systems, some PD and
> some commercial, all of which were developed from scratch.
> As I said, UR/Forth (originally PC/Forth) from LMI was the best.
> This is also why PolyForth stagnated --- it was still 1970s technology
> well into the 1990s --- Charles Moore wasn't upgrading it anymore
> because he had been kicked out of Forth Inc. by Elizabeth Rather.

This is what Anton Ertl says:

On Tuesday, April 30, 2019 at 5:08:01 AM UTC-7, Anton Ertl wrote:

> dxf...@gmail.com writes:
> >I was sceptical given both were ITC but the following appears
> >to confirm. I can only assume F83's 8086 primitives weren't
> >as optimized as they might have been.
> >

> >Integer benchmark 500 loops
> >
> >F83 42s
> >PolyForth 13s
> >DX-Forth (DTC) 13s
>
> Makes me wonder how the alleged piracy worked. Did they hold up the
> Forth, Inc. ship, take its treasures, and then reworked these
> treasures for slowness?

As usual, he is twisting my words to mean something completely
different from what I said. His use of the word "alleged" implies
that Jeff Fox was lying. Anton Ertl is a liar though
(he and Bernd Paysan wrote a EuroForth-2018 paper in which they
blatantly lied when they said that rquotations don't work).

Comparing F83 and PolyForth speed is a straw-man argument.
If PolyForth was faster than F83, this doesn't at all imply
that PolyForth was any good. PolyForth wasn't competitive
with UR/Forth that was the primary professional Forth of the day.

figForth was a pirated version of MicroForth --- figForth was
ported to run on the 6502, which was the popular
personal-computer processor of the day.

figForth was crap, even by the low standards of the 1980s
(it was marginally okay by the super-low standards of the 1970s).
ISYS Forth for the 65c02 (Apple-IIc) was maybe an order of magnitude faster.
ISYS Forth was STC with peephole optimization.
ISYS Forth was far beyond the crude Forth Inc. products!
My cross-compiler was compatible with ISYS Forth --- I was able to
get my symbolic-math program doing derivatives, reducing equations,
and displaying equations with Greek symbols and other math symbols.
I very much doubt this would have been possible with any
commercial C compiler of the day. I was using the full 128KB of the
Apple-IIc, which no C compiler was doing (I still ran out of memory though).