There has been a large Retro computer resurgence over the last few years. In particular the Amiga computer where there is a lot of energy in Amiga due to retro, emulators, other hardware FPGA etc. an example being...

http://www.apollo-computer.com/

I have moved jforth.org back to a more basic, uncluttered, 3.2/4.1 transitional site for Amiga Browsers, removing excess tags, fixed many issues.

I also want to support Forth programming and hopefully bring in more people to learn and appreciate Forth, thus expanding the number of Forth programmers. There are a few barriers newbies need to overcome and climb.

There are plenty of Amiga emulators for Windows, Mac, Linux and Android, see 'No Amiga Anymore', http://www.jforth.org/Amiga-Options.html

There are also useful programming links and Video's.

Anyone interested in playing with JForth and helping, even if it's only on an occasional basis ?

Every little helps.

Regards and best wishes...Martin.

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

On 16/05/2023 2:43 pm, whoami wrote:

There has been a large Retro computer resurgence over the last few years. In particular the Amiga computer where there is a lot of energy in Amiga due to retro, emulators, other hardware FPGA etc. an example being...

http://www.apollo-computer.com/

I have moved jforth.org back to a more basic, uncluttered, 3.2/4.1 transitional site for Amiga Browsers, removing excess tags, fixed many issues.

I also want to support Forth programming and hopefully bring in more people to learn and appreciate Forth, thus expanding the number of Forth programmers.

Never used JForth, however was one of the systems I surveyed circa 2002 for ideas on
floating point output. Being closest to what I was after I was keen to see how they
achieved it. Luckily the source code was supplied. IIRC the output routines weren't
written by JForth's authors but rather donated by another party. So if there was an
inspiration behind my routines, it was JForth.

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

On Monday, May 15, 2023 at 9:43:34 PM UTC-7, whoami wrote:

Anyone interested in playing with JForth and helping, even if it's only on an occasional basis ?

Every little helps.

Regards and best wishes...Martin.

I very much wanted an Amiga back in the 1980s when it came out, but I had no money. :-(

I have read that there was a fast-programming contest in which everybody was given
specs for a program, and the first person with a completed program won. Somebody was using JForth and winning, mostly due to JForth having the traditional
interactive Forth development, and JForth having libraries of general-purpose code.
Who was that? You? Were you involved in developing JForth back in that era?

The Amiga was mostly a platform for video games. Was JForth used for video games?

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

On 19/05/2023 9:04 am, Hugh Aguilar wrote:

I have read that there was a fast-programming contest in which everybody was given
specs for a program, and the first person with a completed program won. Somebody was using JForth and winning, mostly due to JForth having the traditional
interactive Forth development, and JForth having libraries of general-purpose code.

Perhaps this:

https://archive.org/details/Forth_Dimension_Volume_10_Number_5/page/n25/mode/2up

IIRC FIG held several such 'real-time' programming contests. All this at a time
of great variety and activity in Forth as adverts in FD show. Post-ANS the only
question anyone has asked is 'Is it Standard?'

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

On 19/05/2023 1:20 pm, dxforth wrote:

On 19/05/2023 9:04 am, Hugh Aguilar wrote:

I have read that there was a fast-programming contest in which everybody was given
specs for a program, and the first person with a completed program won.
Somebody was using JForth and winning, mostly due to JForth having the traditional
interactive Forth development, and JForth having libraries of general-purpose code.

Perhaps this:

https://archive.org/details/Forth_Dimension_Volume_10_Number_5/page/n25/mode/2up
...

"Claim to fame !!!

Also, Mike and Phil used JForth to win $1000 in the "World's Fastest Programmer" Contest at
Embedded Systems Conference, Anaheim, CA in 1988.

Everyone used Forth but they used an Amiga.

Before the contest they were told to prepare code to read and write to a standard parallel port."

http://www.jforth.org/JF-History.html

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

Also, Mike and Phil used JForth to win $1000 in the "World's Fastest Programmer" Contest at
Embedded Systems Conference, Anaheim, CA in 1988.

Everyone used Forth but they used an Amiga.

Before the contest they were told to prepare code to read and write to a standard parallel port."

http://www.jforth.org/JF-History.html

If I'm correct Forth wasn't that ubiquitous and used on the Amiga
(neither on Atari ST), as it was on PC. Or even on the modest C-64.
So the above was rather an exception than the rule.
From what I remember Amiga was always rather „C-oriented”.

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

On 20/05/2023 12:31 am, Zbig wrote:

If I'm correct Forth wasn't that ubiquitous and used on the Amiga
(neither on Atari ST), as it was on PC. Or even on the modest C-64.
So the above was rather an exception than the rule.
From what I remember Amiga was always rather „C-oriented”.

That's what I remember. Moreover the Amiga was even less programmer-
oriented than the C64. Info was hard to get and expensive.

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

Zbig <zbigniew2011@gmail.com> writes:

From what I remember Amiga was always rather =E2=80=9EC-oriented=E2=80=9D.

Actually AmigaDOS was based on TRIPOS, which was written in BCPL, a
language designed for word-addressed machines, and this is reflected
in the AmigaDOS API; and even after they rewrote all the BCPL stuff in
C, they had to keep this API.

BCPL begat B (by removing features), and B begat C (by adding proper
support for byte-addressed machines).

Forth also started out on word-addressed machines, such as the IBM 1130.

It's interesting how Forth and C differ in incorporating byte addressing.

In B you can access a (word) array with "a[i]", or equivalently
"i[a]", "*(a+i)", "*(i+a)", and in B (on a word-addressed machine)
that is equivalent to Forth "a i + @" (or, if the array element is
written to, "a i + !").

C keeps compatibility with B, and adds types to deal with bytes
(chars) and other kinds of data, such as FP data (float, double),
pointers to these types, etc. You can use all the B syntax variants
in C: If "a" is a pointer to an int (where "int" originally had the
role of the machine word in B, as can be seen by the fact that you
could leave away "int" in a lot of places, and would still get an
int), "a[i]", "*(i+a)" etc. is an array access to it; on a machine
where an int takes 2 bytes, this corresponds to Forth's "a i 2* + @"
(or "... !"). If "a" is a char array, the scale factor is 1, for a
double array it is typically 8, etc.

Forth obviously attacked the problem differently. So if you accessed
a cell array on a IBM 1130 with "a i + @", on a PDP-11 you did it with
"a i 2* + @". For a while byte-addressed machines with 16-bit words
were dominant in the Forth world, and this was reflected in the
Forth-79 and Forth-83 standards. Later 16 bits became too limited and
in Forth-94 we got CELLS, CELL+, FLOATS, FLOAT+, and even CHARS and
CHAR+ to support portability of Forth code between machines with
different cell sizes, different float sizes, and even for character
sizes that are different from the address unit size. So for
performing a read access to a cell array you do

a i cells + @

and for a read access to a float array you do

a i floats + f@

and works (on a standard Forth system) on word-addressed machines as
well as on byte-addressed machines with 16-bit, 32-bit or 64-bit cell
sizes.

So the difference is that C went with compiler-tracked types and
automatic scaling, while Forth stayed without compiler-tracked or run-time-tracked types, and instead requires manual scaling and using type-specific access and computation words.

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

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

On 20/05/2023 2:05 am, Anton Ertl wrote:

...
So the difference is that C went with compiler-tracked types and
automatic scaling, while Forth stayed without compiler-tracked or run-time-tracked types, and instead requires manual scaling and using type-specific access and computation words.

ISTM C and Forth had different goals. One is your traditional compiler- oriented abstracted language in which the user doesn't much care what
comes out the end. The other is closer to a macro assembler in which the
user expects to get what he wrote. Portability (through type declaration)
may be well a goal for the former but less important (if at all) for the
latter as it's machine-oriented. Portability in Forth for the sake of competitiveness with C being an afterthought, it shows.

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

dxforth <dxforth@gmail.com> writes:

On 20/05/2023 2:05 am, Anton Ertl wrote:

...
So the difference is that C went with compiler-tracked types and
automatic scaling, while Forth stayed without compiler-tracked or
run-time-tracked types, and instead requires manual scaling and using
type-specific access and computation words.

ISTM C and Forth had different goals. One is your traditional compiler- >oriented abstracted language in which the user doesn't much care what
comes out the end. The other is closer to a macro assembler in which the >user expects to get what he wrote.

I don't think that the goals were much different. Both started around
1970 and targeted the minicomputers at the time (such as the PDP-11),
and therefore had to deal with the same limitations. Both languages
were close to the machine and started out from a point where the
(predecessor) language only had to deal with machine words, and then
had to cope with byte-addressed machines. C programmers used to know
and still mostly know what happens on the machine about as much as
Forth programmers; and given that C compiled to native code at the
start, with a rather simple compiler, while Forth compiled to threaded
code, C is closer to a macro assembler (although both are not very
close).

Portability (through type declaration)
may be well a goal for the former but less important (if at all) for the >latter as it's machine-oriented. Portability in Forth for the sake of >competitiveness with C being an afterthought, it shows.

Portability is a requirement for people who use different machines,
and want to run their programs across them. Not all C programmers
have that requirement, and not all Forth programmers have it, either.
OTOH, a number of Forth programmers have that requirement, and it has
nothing to do per se with "competetiveness with C", just like Forth
does not have the word "+" "for the sake of competetiveness with C".

Compiler-tracked types were C's solution to the problem of porting B
idioms like "a[i]" to byte-addressed machines, as discussed earlier.
In the Forth world the transition to byte-addressed machines still
happened when Forth was Chuck Moore's personal language, and
apparently he preferred to rewrite the Forth code to use 2* 2+
etc. rather than adding compiler-tracked types to Forth or going
through the contortions that BCPL went through (I don't know exactly
what they are, but the results in the AmigaDOS API did not look
pretty).

One interesting consequence is that Forth is more portable in my
experience than C. The availability of a compiler-tracked type system
seduced the C people to add more and more types (long, short, long
long, and types like int16_t int_least16_t int_fast16_t intptr_t
size_t off_t etc., with different relations between these types on
different platforms, and even on the same platform (e.g., off_t is
32-bit or 64-bit on 32-bit Unix depending on whether and how the macro _FILE_OFFSET_BITS is defined). As a result, you have lots of
different types in a program, with the interactions between them
depending on the actual sizes; while it's possible to write the code
to achieve the intended result, there are so many different types
around and so many interactions that it's easy to overlook some
interactions (and the fact that the syntax mostly hides the type
conversions going on does not help), resulting in a portability bug.

By contrast, in Forth we only few integer types (cells, doubles, and,
only in memory, chars), and when you use a cell where a double is
expected, you notice the mistake in testing independent of whether the
cell size is 16 bits, 32 bits, or 64 bits.

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

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

On Saturday, May 20, 2023 at 11:33:51 AM UTC+1, Anton Ertl wrote:

dxforth <dxf...@gmail.com> writes:

On 20/05/2023 2:05 am, Anton Ertl wrote:

...
So the difference is that C went with compiler-tracked types and
automatic scaling, while Forth stayed without compiler-tracked or
run-time-tracked types, and instead requires manual scaling and using
type-specific access and computation words.

ISTM C and Forth had different goals. One is your traditional compiler- >oriented abstracted language in which the user doesn't much care what >comes out the end. The other is closer to a macro assembler in which the >user expects to get what he wrote.

I don't think that the goals were much different. Both started around
1970 and targeted the minicomputers at the time (such as the PDP-11),
and therefore had to deal with the same limitations. Both languages
were close to the machine and started out from a point where the (predecessor) language only had to deal with machine words, and then
had to cope with byte-addressed machines. C programmers used to know
and still mostly know what happens on the machine about as much as
Forth programmers; and given that C compiled to native code at the
start, with a rather simple compiler, while Forth compiled to threaded
code, C is closer to a macro assembler (although both are not very
close).

Portability (through type declaration)
may be well a goal for the former but less important (if at all) for the >latter as it's machine-oriented. Portability in Forth for the sake of >competitiveness with C being an afterthought, it shows.

Portability is a requirement for people who use different machines,
and want to run their programs across them. Not all C programmers
have that requirement, and not all Forth programmers have it, either.
OTOH, a number of Forth programmers have that requirement, and it has nothing to do per se with "competetiveness with C", just like Forth
does not have the word "+" "for the sake of competetiveness with C".

Compiler-tracked types were C's solution to the problem of porting B
idioms like "a[i]" to byte-addressed machines, as discussed earlier.
In the Forth world the transition to byte-addressed machines still
happened when Forth was Chuck Moore's personal language, and
apparently he preferred to rewrite the Forth code to use 2* 2+
etc. rather than adding compiler-tracked types to Forth or going
through the contortions that BCPL went through (I don't know exactly
what they are, but the results in the AmigaDOS API did not look
pretty).

One interesting consequence is that Forth is more portable in my
experience than C. The availability of a compiler-tracked type system seduced the C people to add more and more types (long, short, long
long, and types like int16_t int_least16_t int_fast16_t intptr_t
size_t off_t etc., with different relations between these types on
different platforms, and even on the same platform (e.g., off_t is
32-bit or 64-bit on 32-bit Unix depending on whether and how the macro _FILE_OFFSET_BITS is defined). As a result, you have lots of
different types in a program, with the interactions between them
depending on the actual sizes; while it's possible to write the code
to achieve the intended result, there are so many different types
around and so many interactions that it's easy to overlook some
interactions (and the fact that the syntax mostly hides the type
conversions going on does not help), resulting in a portability bug.

By contrast, in Forth we only few integer types (cells, doubles, and,
only in memory, chars), and when you use a cell where a double is
expected, you notice the mistake in testing independent of whether the
cell size is 16 bits, 32 bits, or 64 bits.
- 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 2022: https://euro.theforth.net

in

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

On 20/05/2023 7:32 pm, Anton Ertl wrote:

dxforth <dxforth@gmail.com> writes:
...

Portability (through type declaration)
may be well a goal for the former but less important (if at all) for the
latter as it's machine-oriented. Portability in Forth for the sake of
competitiveness with C being an afterthought, it shows.

Portability is a requirement for people who use different machines,
and want to run their programs across them.

An author is well-placed to port his program across his different machines.
The effort is in writing code that will work on machines different than
one's own, and finding an audience for it. Is there one - because I've
not seen anyone put up their hand. Displeasure from folks whose efforts
were rejected is about all.

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

I occasionally want to write a lot of 'C', and the more interesting
the program, the larger the struggle with types and macro's [..]

Exactly.

A big advantage of 'C' is that there are no Forth-like surprises
(granted, in 2000+ source files some bisons and yaccs can hide).
With Forth, the author(s) may decide to redefine a kernel word
or (silently) use a non-standard extension

If I'm correct the whole point regarding programming in Forth
is creating many-many non-standard extensions… ;)

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

On Saturday, May 20, 2023 at 12:33:51 PM UTC+2, Anton Ertl wrote:

dxforth <dxf...@gmail.com> writes:

On 20/05/2023 2:05 am, Anton Ertl wrote:

...
So the difference is that C went with compiler-tracked types and
automatic scaling, while Forth stayed without compiler-tracked or
run-time-tracked types, and instead requires manual scaling and using
type-specific access and computation words.

ISTM C and Forth had different goals. One is your traditional compiler- >oriented abstracted language in which the user doesn't much care what
comes out the end. The other is closer to a macro assembler in which the >user expects to get what he wrote.

I don't think that the goals were much different. Both started around
1970 and targeted the minicomputers at the time (such as the PDP-11),
and therefore had to deal with the same limitations. Both languages
were close to the machine and started out from a point where the (predecessor) language only had to deal with machine words, and then
had to cope with byte-addressed machines. C programmers used to know
and still mostly know what happens on the machine about as much as
Forth programmers; and given that C compiled to native code at the
start, with a rather simple compiler, while Forth compiled to threaded
code, C is closer to a macro assembler (although both are not very
close).

I occasionally want to write a lot of 'C', and the more interesting
the program, the larger the struggle with types and macro's, especially
in debug mode (the debugger can't expand a macro at that point).

A big advantage of 'C' is that there are no Forth-like surprises
(granted, in 2000+ source files some bisons and yaccs can hide).
With Forth, the author(s) may decide to redefine a kernel word
or (silently) use a non-standard extension (I certainly will do that
myself). Without good documentation or a nice test suite this
can make it impossible to track down why stuff won't work.

-marcel

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

Marcel Hendrix <mhx@iae.nl> writes:

A big advantage of 'C' is that there are no Forth-like surprises
(granted, in 2000+ source files some bisons and yaccs can hide).
With Forth, the author(s) may decide to redefine a kernel word
or (silently) use a non-standard extension (I certainly will do that
myself).

Such surprises don't sound particularly Forth-like to me.

Gforth uses a number of GNU C extensions, so we did not expect it to
work with any compiler but gcc. Interestingly, over time Intel's icc,
tcc, llvm-gcc and clang acquired the most important ones; icc crashed
on compiling Gforth when I tried it (maybe 25 years ago, so that may
have changed), tcc worked with minor tweaks, and llvm-gcc and clang
work (but clang needs much longer than gcc).

Another thing is that Gforth has a configure.ac file (currently 1888
lines, expanding into a 21590-line configure script) that papers over differences between systems, among other things.

One difference is that C compiler maintainers seem to be more willing
to pick up extensions from other C compilers, as demonstrated by the
extensions used by Gforth, while Forth compiler writers are more
idiosyncratic.

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

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

On Saturday, May 20, 2023 at 3:33:51 AM UTC-7, Anton Ertl wrote:

Portability (through type declaration)
may be well a goal for the former but less important (if at all) for the >latter as it's machine-oriented. Portability in Forth for the sake of >competitiveness with C being an afterthought, it shows.

This is just DXforth's endless stream of drivel in which he hates the
idea of Forth standard, and claims that it puts his awesome creativity
in a box. Anton Ertl is making a fool out of himself by responding to
DXforth because this stream of drivel will obviously never end.

Portability is a requirement for people who use different machines,
and want to run their programs across them. Not all C programmers
have that requirement, and not all Forth programmers have it, either.
OTOH, a number of Forth programmers have that requirement, and it has nothing to do per se with "competetiveness with C", just like Forth
does not have the word "+" "for the sake of competetiveness with C".

Portability is important for all programmers. This allows them to avoid
vendor lock-in. This allows the programming language to become a
serious language, not just a weird offering by a lone company. The
programming world is not going to accept a language that is unique
to a single company because that company might go out of business
or might (very likely) raise their prices after they have their customers trapped in vendor lock-in.

Portability is what the vendors hate and fear more than anything,
whereas vendor lock-in is their goal. This is why Stephen Pelc was the
worst possible choice to be chairperson of the Forth-200x committee.
His effort to cripple Forth-200x with idiotic design decisions was
very blatant and heavy-handed. He killed the rquotations that have the
feature of accessing the parent quotation's local variables. He
standardized the Paysan-faked quotations that are just :NONAME with
some syntactic sugar but fail to support general-purpose data-structures
(the Paysan-faked quotations do exactly the same thing that my pseudo-quotations did back in 2010 --- no advantage whatsoever!).
It was painfully obvious that he wanted Forth-200x to be crippled and
VFX to have rquotations as a proprietary feature. Ultimately, Stephen Pelc hates and fears Forth programmers --- he wants everybody on
comp.lang.forth to be his customer ($$$), but to never write any Forth code that
could possibly be in competition with VFX --- for vendors, it is all about money.

A viable Forth standard, if we ever get one, will be designed by Forth programmers,
and this will be done despite every effort by the Forth compiler vendors to prevent it.

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

On 22/05/2023 9:08 am, Hugh Aguilar wrote:

Portability is important for all programmers. This allows them to avoid vendor lock-in.

Portability is what the vendors hate and fear more than anything,

A viable Forth standard, if we ever get one, will be designed by Forth programmers,
and this will be done despite every effort by the Forth compiler vendors to prevent it.

This is just DXforth's endless stream of drivel in which he hates

What have I to hate - vendors locking me in, an non-viable standard or folks that don't do what I want? ISTM I have little left to hate. Try it - you
may come to like it.

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

Actually lack of portability means more work — therefore
increased demand — for the programmers… someone has
to „port” the particular program for the other system, correct?

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

On 22/05/2023 8:28 pm, Zbig wrote:

Actually lack of portability means more work — therefore
increased demand — for the programmers… someone has
to „port” the particular program for the other system, correct?

That's providing portability. There's money in that? Perhaps
portability is an ideal for which folks are prepared to spend
rather than get paid.

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