Forth is the programming language of the future

1375 views
Skip to first unread message

Manuel Rodriguez

unread,
Dec 28, 2018, 3:35:44 AM12/28/18
to
If somebody is trying to program a computer or a smartphone he has the
choice between many programming languages. The latest example of a well
working language is Golang which was introduced in 2009 and provides some
new features. In contrast to C++ and Python, the Go language looks very
modern and future ready. The reason is, that the language was designed
from scratch and provides a lot of libraries which makes it suitable
for developers who wants to create their first apps. Go was developed
similar to C++ for practical usage.

If the mainstream ecosystem is working great, why the world needs
Forth? It's a good question. On the first look, Forth can't be compared
with modern programming languages and it's hard to do simple things. In
go, it is very easy to create a GUI, a webbrowser or a primenumber
generator, while Forth lacks in everything. It has no garbage collector,
no GUI libraries, and no nothing at all. Understanding Forth is only
possible if the expectation of the developer will change. The strength of
Forth is, that no standard is there. Instead the developer has to invent
everything from scratch. If he want's to program with object-oriented
style nobody will hold him back. If he want's to allocate lots of
memory, he is welcome. The reason why Forth is working better than
managed languages like C++ is, that only with Forth the programmer
has control over his computer. He isn't forced to follow anybody. That
means, there is no compiler which is used by everybody, and there is no
collection of libraries which allows him to write the first gui app in
under a minute. The missing features in Forth are the main strength of the
language. If the language comes without guidelines and without predefined
functions, the developer is in charge to deliver the missing parts.

Forth is a programming language not invented yet. It's very similar to
the book “Linux from scratch” which is not an operating system but
a guideline how to create an operating system. Forth can be seen as
a true metalanguage. Even the well known Forth primitives like swap,
dup and mod are not standardized, which means they have to be invented
in each Forth system by it's own.

Mainstream computer languages like Java or Python can be seen as the
answer to a problem. Java, for example answers the question of how to
program platform independent code. The programmer has to read the manual,
understands the concepts behind Java and follows the community. Forth is
working the other way around. It doesn't provide knowledge, Forth asks
for knowledge. In mainstream programming languages, the newbie gets a
shiny compiler for running the sourcecode. In Forth, the newbie has to
write the compiler as his first project. That is the reason, why Forth
is loved by computer professionals. It gives them the opportunity to
learn, to make mistakes and to bring technology forward. My prediction
is simple: in 20 years, all the mainstream languages are gone. C# will
become obsolete and nobody will remember the PHP scripting language,
but Forth will become the industry standard.

* How to get started *

The Forth language makes it hard for newbies to get started. .The reason
is, that Forth doesn't provide sourcecode and the available Forth Virtual
machines can't be recommended anymore. But if nothing is there, what
should the newbie learn? What are the do's and dont's? The reason why
Forth is nearly invisible has to do with, that it's a virtual machine. A
VM is a game similar to a cardgame. The rules of the Forth game can be
written down in a single sheet of paper. But for playing the game right,
this description is not sufficient. What the beginner needs are additional
information about Forth. I can't recommend a single book. The inventor
is Chuck Moore and he has written some books about Forth, but they are
not the best starting point. What i recommend is to use a search engine
like google and search in the existing fulltext of all publications.

Here is my recommended Google search string, it contains of some keywords
which reduce the internet to Forth related information. At the end of
the string, the user can put his own topic of interesting for example he
can add “Forth CPU” if he is interested in Forth in Hardware, or he
can add “benchmark” if he is interested in a performance comparison
with a classical programming language.

["Rochester Forth Conference" OR "Journal of Forth Application and
Research" OR "Forth assembly" OR "Forth programming" OR "ACM SIGFORTH"
OR "Forth Dimensions" OR "euroForth" OR "figForth" OR "euroFORML" OR
“FORML Conference” OR “SVFIG” OR site:forth.org OR site:forth.com]
filetype:pdf

Forth itself can't described in a book or in software. But the
literature around Forth can be collected and searched by a fulltext
search engine. That means, the amount of blogs, pdf papers and books
about Forth is forming the corpus. And what is available in the corpus
is similar to Forth. Something in the collection is wrong or outdated,
but this is normal in every community. If we are searching for information
about robotics, we will notice the same problem. What is special in the
Forth corpus is, that the total amount of information is limited. It is
very common, that Google doesn't find a single result for a keyword. That
means, the information is simply not there, it was not written down. Let
us take a detailed look into the keyword list. They are about academic
journals like the “Journal of Forth Applications”, it contains the
famous forth.org website and also the Forth Dimension journal. I would
guess, that most of available Forth literature will be found with that
searchstring. Some Forth related information are only available as printed
books, some are out of print and no longer available. So it's important
to write new Forth tutorials from scratch to add the missing information.

jpit...@gmail.com

unread,
Dec 28, 2018, 4:34:47 AM12/28/18
to
https://www.google.com/search?q=Books+about+Forth&rlz=1C1CAFA_enGB781GB781&oq=Books+about+Forth&aqs=chrome..69i57j0l3.5559j0j7&sourceid=chrome&ie=UTF-8
https://www.mpeforth.com/books.htm
https://www.forth.com/forth-books/
https://github.com/ForthHub/ForthFreak/wiki/Forthfreak-wiki

I am rather surprised to read that 50 years of Forth has not produced sufficient material to learn Forth.
We all learn differently – so none of the material might fit how you learn
– but the successes of Forth over the years must have been achieved by people who had to learn Forth – and then applied it successfully.
I tried the link given, but it did not show what I wanted – google sees everybody’s demands differently.
Instead I just asked google about “Books about Forth”.
And ended up at what the Forth Compiler Suppliers suggest for example.
And you can always look at the Forth Bookshelf.
The classic being Starting Forth.
The one I would recommend from the bookshelf is A Start With Forth – to my knowledge the most recent Forth overview – and a lot for download and try out at
https://wiki.forth-ev.de/doku.php/en:projects:a-start-with-forth:start0.
Try Invent A Language
12 Words as Start
35 words – A training I gave to a group – 2 hours and the basics were understood.
Easyforth with no installation – just try it in your browser.
VFXTESTAPP – a VFX targeted as easy download and to learn with – SAVE to keep what you have done.
Regarding Learning Forth there is a starting point – and there is a target,
and this was unfortunately not defined in this post – so how can you define a route to get there?

Mark Wills

unread,
Dec 28, 2018, 5:02:35 AM12/28/18
to
On Friday, 28 December 2018 08:35:44 UTC, Manuel Rodriguez wrote:
It's a nice essay, but your main point, that C# etc. will
become obsolete to be replaced by Forth is not backed up
with any supporting arguments or evidence.

5/10.

Liang Ng

unread,
Dec 28, 2018, 6:09:01 AM12/28/18
to
On Friday, 28 December 2018 18:02:35 UTC+8, Mark Wills wrote:
> It's a nice essay, but your main point, that C# etc. will
> become obsolete to be replaced by Forth is not backed up
> with any supporting arguments or evidence.
>
> 5/10.

What you wanted is here, in another thread:

https://groups.google.com/d/msg/comp.lang.forth/cAZURahAnzg/4KdMNH3pDAAJ

NN

unread,
Dec 28, 2018, 6:36:45 AM12/28/18
to
On Friday, 28 December 2018 08:35:44 UTC, Manuel Rodriguez wrote:
> If somebody is trying to program a computer or a smartphone he has the
> choice between many programming languages.

..... The only "persons" programming computers or smartphones in the future will be other computers and smartphones.

In fact we wont have smartphones in the future because we will have smart watches.

So what were you saying ...?

peter4...@gmail.com

unread,
Dec 28, 2018, 7:50:33 AM12/28/18
to
Forth literature over 80 books , papers and documents on Forth

you can find here :

https://sites.google.com/view/win32forth/books-on-forth


a modern Forth with GUI ANSI is Win32forth , free and with full sources :

read my opinion about it here : https://sites.google.com/view/win32forth/home


videos how to install it, and some tricks : look for Win32forth on Y2B
my channel is Peter Forth , start here :

https://www.youtube.com/watch?v=5MnUkdNTq6s

peter4...@gmail.com

unread,
Dec 28, 2018, 7:52:35 AM12/28/18
to
Win32forth graphics parallel processing, games,OpenGL, etc
the site of Jos Ven is the best.

https://sites.google.com/site/win324th/

Albert van der Horst

unread,
Dec 28, 2018, 7:58:39 AM12/28/18
to
In article <4d3acddf-29fd-4e87...@googlegroups.com>,
Manuel Rodriguez <a...@gmx.net> wrote:
>If somebody is trying to program a computer or a smartphone he has the
>choice between many programming languages. The latest example of a well
>working language is Golang which was introduced in 2009 and provides some
>new features. In contrast to C++ and Python, the Go language looks very
>modern and future ready. The reason is, that the language was designed
>from scratch and provides a lot of libraries which makes it suitable
>for developers who wants to create their first apps. Go was developed
>similar to C++ for practical usage.

Go is modern?

Go is a rehash of algol68.
http://cowlark.com/2009-11-15-go/index.html
It misses the mistakes that are added in the way to C++/Java.

It is probably better, it should be with 50 years (!) of hindsight.

Interestingly, modern Forth or lisp have no fundamental edge over
'68 vintage Forth or Lisp either.
It is hard to come up with something really new.

By all means, use Golang. It would be progress if it replaced Mycropython.
I'll stick with Forth.

Groetjes Albert
--
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

Albert van der Horst

unread,
Dec 28, 2018, 8:07:32 AM12/28/18
to
In article <50eea968-74c7-486e...@googlegroups.com>,
<peter4...@gmail.com> wrote:
<SNIP>
>
>a modern Forth with GUI ANSI is Win32forth , free and with full sources :
>
>read my opinion about it here : https://sites.google.com/view/win32forth/=
>home

win32forth is nice, but it is doomed. Married to Microsoft and 32 bits
only. It will be extinct with the next mass-extinction.

Only bacterial-size Forth's like ciforth will survive.
In the first place they have no problem migrating between eco-systems
and actually have.

peter4...@gmail.com

unread,
Dec 28, 2018, 9:09:21 AM12/28/18
to
On Friday, December 28, 2018 at 6:35:44 AM UTC-2, Manuel Rodriguez wrote:
Manuel,

With Forth actually you go nowhere in the professional programming world.

There are no toolchains for Forth in any OS. So I really doubt you will
progress with your search of Forths for a smartphone.

The only I have found as I went back to forth 3 years ago, was Win32forth(for PCs).
(since I am using it for hobby , and learning, I did not want to use
VFX or Swift, they do not provide the sources, I tried them out but I did not
like theirs IDE and were not complete for easy GUI development or out of reach for hobby applications)

On Win32forth you have the complete sources of any single byte on the code you are
running, and you can create turnkey applications on windows snapping your fingers.

There are tons of examples for any kind application you want to create, from
GUI Interface at all levels, console applications, to simple graphics, file access,
dbase interface , wordprocessing, editors,asm, disassembler, more complex graphics over OpenGL, serial IO, net etc... There is even not only the Form
designer , but also the VisualForth from Dirk to help you creating attractive
modern interefaces.
And there is still an active community working on it,and creating some new programs
and examples . I am doing that and I am also creating some VIDEOS teaching some tricks
and showing what Forth is able to do.
One of the last projects, I showed an interface to the Nodemcu an IOT device, and examples
how you can do that very easily (much better than any Python or C++ stuff) with Win32forth
and using Punyforth another modern forth for IOT. I still have some unfinished work (newer programs
on Win32forth) and will do some videos, hope I get time free during 2019 to publish them on Y2B.

Mr. Pintaske, may have much knowledge on trolling or how to humillate forth programmers with his insults on public Forth forums, using the great master names of the community like Mr. Moore or Dr. Ting, as shield for his felonies.
But on Forth programming he is a complete ignorant, promoting
40 or 50 year old texts, out of modern programming reality to a group of colletctors of antiquity, without index, and with a foreword written by
an 8 year old child.

For example :
Recommending a 35 words forth for a newby is an affront to the intelligence of the poor man.
Nobody can go nowhere with a 40 year old Forth today written for 8 bit cpus, except ridicularize yourself, when we have at 0.50- 1,00 U$S CPU with MMU on board, GPU, 1000 registers, and DSP barrel multiplier on board, and 64 bits.
This is a dead road, that only ends in frustration. Therefore, the insults
and the irratibility are on top of the list. There are no tools, there is no simple
float math in it, it has no OS interface, so you can do absolutly nothing
and worser you have to learn RPN to work with that old shoe !

Take for example the RPI, if you offer to the newbies that wants to learn a programming
language , a 35 words Forth , they can´t simply light a led on an off ! They
will laugh at you, or comparing this to Python they will think he is completly mad. If you can´t print
"Hello world" to the screen, or you can´t program a simple RC servo for a toy Robot, as
the own Pintaske could not (even using VFX he is so proud to recommend), and was asking for help on the forums.
And as I inocently asked him : "Why don´t you
ask this to Phelc *" he went mad,because he has no clue in Forth programming, and started
using pejorative terms offesive slang and insulting a lot letting everybody know
(outside and inside the Forth community)
how impotent and frustrated he feels with forth 35 words or VFX, he using both
Forths unable to program a Toy for an 8 year old child ! :)

Unsing the above example, you can extrapolate the rest.. and see why
Forths are not used any more as programming language at all. You have not the right tools.
With all my respect to the great master Dr. Ting.
But he offered an ESP8266 eforth without the wifi words. So a modern chip (one of the easiest to access and buy today) born for IOT and WIFI , had to be used without Wifi(the purpose of its existance) because of incomplete Forth implementations...

The question is for what somebody would enter into that sinking ship ?
My nephew has an Arduino IDE
(for free) that has WIFI libraries, and he is able to program the ESP8266 in flat 2 minutes and make a web-server or an IOT device to run like a clp...
(Of course I triyed to convince him of forth, but he laughed at me ! )

Modern CPUs need an OS they are too complicated devices to be used without them. OSes are written
by teams of hundreds of programmers (like mPhyton, like Expressif, like Rtos, etc etc etc). Expressif for Nodemcu had 600 programmers writing the routines
for Wifi and MMU, etc.
If you look at Go or Android you see monster software companies with 10thausend 20thausend programmers
behind those gigantic projects. Nowadays we can not put together 5 Forth programmers to work on the same project.

So the rest is only illusions or fantasy.

I know there are some retroprogrammers that still continue to see the world
with eyes of 8 Bit CPU of 1978. I do not talk to the ones they still like
Forth as a hobby and program backwards on old platforms.
For them all my respect ! I like your work very much.

But there are other dreamers, without clue, talking on 2018-19, with the same
concepts of 1970 they seem to live in a parallel world.

In the universe where we live with our actual laws of physics acting normally
day by day, as we know and studied, there will be no Forth for Smartphones, no Forths in future for AI or for the tensor programming model, because it would be absolutely inproductive to program in Forth such applications.



Ilya Tarasov

unread,
Dec 28, 2018, 11:29:17 AM12/28/18
to
Trying to reproduce 40-years old approach with Forth, we are really going to nowhere. However, why we need to do it? I mean why we need to write OS, smartphone applications, GUI etc. There are a lot of applications where key Forth features as scripting, language flexibility and compactness may be used.

I cannot agreed there is no Forth for <technology name>. We can script TensorFlow, OpenCV or something like this. We can deal with API with a help of Forth shell. The only questions is are we really need Forth features, or it is just an attempt to highlight well-known technology? As I can see, agressive pushing Forth has almost zero productivity, with predictable answers (or just laughing). As a glueware or embedded tool, Forth is a good approach and will be alive for a long time.

jpit...@gmail.com

unread,
Dec 28, 2018, 1:11:18 PM12/28/18
to
L O L - This Forth guy is quite clearly a Copyright Criminal - or additionally as well incapable of reading. Stolen my work prepared from my website:

Stating Forth

stating quite clearly :

The original print edition of Starting FORTH is copyrighted by FORTH, Inc. and all rights are reserved. Permission has been granted to Juergen Pintaske to make this PDF of the on-line version of the work available and to make
certain modifications to the original printed work.
Further reproduction (except for the printing of single copies for
personal use), modification, distribution, posting on other web sites, or unauthorized use of either the printed or online version of Starting FORTH by any party other than Juergen Pintaske is expressly forbidden without prior written permission from: FORTH, Inc. 5959, W. Century Blvd. Suite 700, Los Angeles, CA 90045 USA,
www.forth.com
For personal print out formatted from web .
Enjoy. Download from www.exemark.com Juergen Pintaske 2013_12_24


And this seems to be his major work - stealing another of my prepared books - and he is silly enough to boast with this on his website -

What a wonderful day - he fell into the trap.

And by the way - the Forth Books I have published are the only ones visible on the amazon Compiler Bestseller list https://www.amazon.com/gp/bestsellers/books/3970/ref=pd_zg_hrsr_b_1_5_last#5

About 10% there for Forth - not too bad ...

Well, at least normal people do appreciate the work - clf is a completely different story - and my published books are for people who are interested in the theme - proven to be helpful for the last 5 years. And probably for the next 20 years.

jpit...@gmail.com

unread,
Dec 28, 2018, 1:56:08 PM12/28/18
to
On Friday, 28 December 2018 16:29:17 UTC, Ilya Tarasov wrote:
> Trying to reproduce 40-years old approach with Forth, we are really going to nowhere. However, why we need to do it? I mean why we need to write OS, smartphone applications, GUI etc. There are a lot of applications where key Forth features as scripting, language flexibility and compactness may be used.
>
> I cannot agreed there is no Forth for <technology name>. We can script TensorFlow, OpenCV or something like this. We can deal with API with a help of Forth shell. The only questions is are we really need Forth features, or it is just an attempt to highlight well-known technology? As I can see, agressive pushing Forth has almost zero productivity, with predictable answers (or just laughing). As a glueware or embedded tool, Forth is a good approach and will be alive for a long time.

Ilya, I mostly did these eBooks and Print Books to promote Forth, for fun and to learn a bit about Forth myself.
The market decides anyway about any interest - and there are people buy them. ( sorry to use the word market here )

And I assume that many of the people here have learnt Forth using similar material.
So nothing has really changed except that new people use it for the same purpose.
I would prefer the availability of more modern Forth books as well - but it seems there are none.

minf...@arcor.de

unread,
Dec 28, 2018, 2:41:30 PM12/28/18
to
Am Freitag, 28. Dezember 2018 19:56:08 UTC+1 schrieb jpit...@gmail.com:
> And I assume that many of the people here have learnt Forth using similar material.

I think most have learnt it the hard way: by DOING s.th. with Forth.
Not by reading books, that came later. Trying to understand code listings
was the way, sometimes sparsely documented by shadows blocks.

> So nothing has really changed except that new people use it for the same purpose.
> I would prefer the availability of more modern Forth books as well - but it seems there are none.

What should a modern Forth book contain when there are no modern concepts?

IMO the "changes" since Forth-79 are rudimentary. No dumb bashing intended,
it only shows that the programming requirements for small/est devices have
also not changed much over the years. Many manufacturers of small boards
offer C compilers plus driver libraries along with the boards. That hasn't
changed either.

peter4...@gmail.com

unread,
Dec 28, 2018, 4:06:41 PM12/28/18
to
Pintaske, you are a shame for the programming community.

What does it mean "criminality", are you threatening me because I write the
words "Starting Forth" in a public programming forum ?

What criminality are you talking about, are you stupid, crazy , or both things ?

You are making yourself a full time idiot of the Forth forums.

I regret so much, such prestigious Forth authors have fallen in your
trap. The trap of an ignorant without manners , that helps to destroy
Forth a bit more each day.

And now pretends to put under copyright all the history of forth.

You are totally out of your mind !




dxf...@gmail.com

unread,
Dec 28, 2018, 7:58:14 PM12/28/18
to
I'm sorry but this is the 'born again Forther' phenomena that c.l.f.
has seen many times before. They come with yet another plan to
save Forth with high hopes and much rhetoric and invariably leave
disillusioned.

dxf...@gmail.com

unread,
Dec 28, 2018, 8:23:33 PM12/28/18
to
On Saturday, December 29, 2018 at 12:07:32 AM UTC+11, Albert van der Horst wrote:
> In article <50eea968-74c7-486e...@googlegroups.com>,
> <peter4...@gmail.com> wrote:
> <SNIP>
> >
> >a modern Forth with GUI ANSI is Win32forth , free and with full sources :
> >
> >read my opinion about it here : https://sites.google.com/view/win32forth/=
> >home
>
> win32forth is nice, but it is doomed. Married to Microsoft and 32 bits
> only. It will be extinct with the next mass-extinction.

Commercial systems too. Big and bulky they serve their clients
for as long as the latter exist. Standards, which are there to
support the interests of the mega-forths, are similarly doomed.

>
> Only bacterial-size Forth's like ciforth will survive.
> In the first place they have no problem migrating between eco-systems
> and actually have.

Chuck once said Forth should be small enough that it can be thrown away
and rebuilt from scratch. In contrast we want our forths and standards
to go on forever as absurd as such notions are.

"Look back over the past, with its changing empires that rose and
fell, and you can foresee the future, too."

hughag...@gmail.com

unread,
Dec 28, 2018, 9:51:35 PM12/28/18
to
On Friday, December 28, 2018 at 6:23:33 PM UTC-7, dxf...@gmail.com wrote:
> Standards, which are there to
> support the interests of the mega-forths, are similarly doomed.

This makes no sense!

1.) The purpose of a standard is to allow programs and code-libraries to be portable between different compatible systems.
For this to work, there obviously have to be more than one system in use.
So a standard is more useful for multiple small systems, rather than a few "mega-Forths."

2.) Neither Forth Inc. nor MPE are mega-sized companies.
They are both very small companies.
Even small plumbing companies employ an order of magnitude more people,
and make an order of magnitude more money.

For Forth to grow, there needs to be a meaningful standard
that supports general-purpose data-structures (real quotations are needed),
and allows programs and code-libraries to be portable.
In this case, there will arise multiple Forth systems that adhere to the standard,
and the Forth community will grow.
This is the future that Forth Inc. and MPE are striving to prevent.

Bob Armstrong

unread,
Dec 28, 2018, 10:01:27 PM12/28/18
to
Forth is the foundation . Everyday use is why I've built a reference counted APL in it .

Albert van der Horst

unread,
Dec 29, 2018, 8:37:38 AM12/29/18
to
In article <66b64e7b-2b72-4a51...@googlegroups.com>,
Ilya Tarasov <ilya74....@gmail.com> wrote:
>Trying to reproduce 40-years old approach with Forth, we are really going t=
>o nowhere. However, why we need to do it? I mean why we need to write OS, s=
>martphone applications, GUI etc. There are a lot of applications where key =
>Forth features as scripting, language flexibility and compactness may be us=
>ed.
>
>I cannot agreed there is no Forth for <technology name>. We can script Tens=
>orFlow, OpenCV or something like this. We can deal with API with a help of =
>Forth shell. The only questions is are we really need Forth features, or it=
> is just an attempt to highlight well-known technology? As I can see, agres=
>sive pushing Forth has almost zero productivity, with predictable answers (=
>or just laughing). As a glueware or embedded tool, Forth is a good approach=
> and will be alive for a long time.

I agree wholeheartedly, but the ultimate glueware at this moment is
micropython. Our niche has been taken.

hughag...@gmail.com

unread,
Dec 29, 2018, 10:02:04 AM12/29/18
to
On Saturday, December 29, 2018 at 6:37:38 AM UTC-7, Albert van der Horst wrote:
> In article <66b64e7b-2b72-4a51...@googlegroups.com>,
> Ilya Tarasov <ilya74....@gmail.com> wrote:
> >I cannot agreed there is no Forth for <technology name>. We can script Tens=
> >orFlow, OpenCV or something like this. We can deal with API with a help of =
> >Forth shell. The only questions is are we really need Forth features, or it=
> > is just an attempt to highlight well-known technology? As I can see, agres=
> >sive pushing Forth has almost zero productivity, with predictable answers (=
> >or just laughing). As a glueware or embedded tool, Forth is a good approach=
> > and will be alive for a long time.
>
> I agree wholeheartedly, but the ultimate glueware at this moment is
> micropython. Our niche has been taken.

In 1994 when I was at Testra, I should have told them:
"Before the MiniForth processor can be used,
we need to wait for MicroPython to be invented, so it can be glueware
for C code written by somebody smarter than us!" ;-)
That would have certainly marked my last day on the job.
Of course, it can be argued that my last day on the job did come eventually,
although that was after I wrote MFX for the MiniForth.

Any application that uses MicroPython is going to be soft real-time at best.
You aren't going to do hard real-time with a dynamic-OOP language featuring GC.
Also, you are going to need a 32-bit ARM Cortex for your application,
although a 16-bit Forth processor would have been adequate.

I haven't really looked at Ilya Tarasov's processors.
He's competing on the basis of performance and price though,
so I assume they are 16-bit.

hughag...@gmail.com

unread,
Dec 29, 2018, 10:49:17 AM12/29/18
to
Liang Ng seems to be an academic --- a lot of hot air and speculation ---
a lot more interested in writing papers than in writing code that works.

Manuel Rodriguez is almost certainly a sock-puppet of Rod Pemberton.
He writes very lengthy posts that are entirely nonsense,
which is the exact same style as Rod Pemberton who seems to have disappeared.

On Friday, December 28, 2018 at 1:35:44 AM UTC-7, Manuel Rodriguez wrote:
> On the first look, Forth can't be compared
> with modern programming languages and it's hard to do simple things.
> ...
> Understanding Forth is only
> possible if the expectation of the developer will change. The strength of
> Forth is, that no standard is there. Instead the developer has to invent
> everything from scratch.

This guy is not trying to save Forth. He is mocking Forth.
He is playing the "Devil's Advocate" by pretending to praise Forth while
ridicularizing Forth by saying that it lacks all useful features
(note that "ridicularize" isn't a real word; Peter coined the term).
The goal of "Manuel" is to convince everybody that C is the "god language"
(note that Rod Pemberton coined the term "god language" for C).

I admit though, that the 32-bit processors are pretty inexpensive nowadays.
In 1994, the competition in the laser-etching business was using an
MC68000 programmed in C. The MiniForth beat that on both price and performance.
Those days are past. The MC68000 evolved into the ColdFire that is now obsolete.
Beating the ARM Cortex on price or performance is much more difficult.
I don't know of any application in which Forth would be a win on both
price and performance (maybe one or the other though).
If I knew this, I would be working as a programmer rather than a plumber.

foxaudio...@gmail.com

unread,
Dec 29, 2018, 11:43:41 AM12/29/18
to
On Friday, December 28, 2018 at 10:01:27 PM UTC-5, Bob Armstrong wrote:

> Forth is the foundation . Everyday use is why I've built a reference counted APL in it .

Here here!

I have always felt that after the first page or two, one should not be programming in Forth but
rather in the new language that you create for the problem domain.

You Bob, have taken this concept to completion.

There is nothing preventing the creation of other language abstractions from being loaded
onto to Forth to simplify coding in different domains.

Perhaps, just perhaps, we have fallen into a trap by of thinking of "libraries" rather than
languages as the correct way to extend Forth's usefulness.


Ilya Tarasov

unread,
Dec 29, 2018, 12:48:56 PM12/29/18
to

> Ilya, I mostly did these eBooks and Print Books to promote Forth, for fun and to learn a bit about Forth myself.
> The market decides anyway about any interest - and there are people buy them. ( sorry to use the word market here )
>
> And I assume that many of the people here have learnt Forth using similar material.
> So nothing has really changed except that new people use it for the same purpose.
> I would prefer the availability of more modern Forth books as well - but it seems there are none.

We need many books about different aspects of Forth programming. Telling 10 times how smart Forth is looks useless because other authors are active too and promoting their favourite languages. Books are just one of possible activities, and should follow actual trends. I think discussing those trends more interesting.

hughag...@gmail.com

unread,
Dec 29, 2018, 1:53:12 PM12/29/18
to
All of the books I've seen on Forth are too simplistic.
Peter makes a good point:

On Friday, December 28, 2018 at 7:09:21 AM UTC-7, peter4...@gmail.com wrote:
> Recommending a 35 words forth for a newby is an affront
> to the intelligence of the poor man.

Actually, the Forth Inc. books are not much better. None mention structs at all.
I've never seen any Forth book that got past novice-level programming.
All books on C describe structs. Most are still novice-level though.
A few books on C, Python, etc. that delve into intermediate-level topics.

There are very few Forth programmers delving into anything very advanced.
I'm not aware of any c.l.f. enthusiast who is beyond intermediate-level.

Ilya Tarasov may be at the advanced level.
I would have to examine his Forth system to verify this.
He seems reasonably intelligent though. He is not just blowing hot air.

Ilya: If you want to corroborate on a Forth book with me, contact me by email.
I've already thought of a good title: "Intermediate-Level Forth Programming."
There would be a heavy emphasis on meta-compiling, including a cross-compiler.
Publish both English and Russian versions to double the market!
The market may still be less than 20, so don't expect to get rich doing this.

Certainly, only advanced-level Forth programmers are qualified to write a book
on intermediate-level Forth.
When intermediate-level Forth programmers try to write a book, they invariably
come up with yet-another novice-level book.
When novice-level Forth programmers try to write a book, they invariably
come up with a pile of nonsense (https://www.forth.com/forth-books/).

m...@iae.nl

unread,
Dec 29, 2018, 3:26:22 PM12/29/18
to
On Saturday, December 29, 2018 at 5:43:41 PM UTC+1, foxaudio...@gmail.com wrote:
> On Friday, December 28, 2018 at 10:01:27 PM UTC-5, Bob Armstrong wrote:
[..]
> Here here!
>
> I have always felt that after the first page or two, one should not
> be programming in Forth but rather in the new language that you
> create for the problem domain.
>
> You Bob, have taken this concept to completion.
>
> There is nothing preventing the creation of other language
> abstractions from being loaded onto to Forth to simplify
> coding in different domains.
>
> Perhaps, just perhaps, we have fallen into a trap by of thinking
> of "libraries" rather than languages as the correct way to extend
> Forth's usefulness.

I think you are onto something. A "word" in Forth is vastly
more powerful than a conventional subroutine that is meant to be
combined with other subroutines in some linear fashion.

A small segment of Forth source may look familiar, but that
does not give you *any* guarantee of what will happen when it is
executed. It is not just that we do not know what each individual
word does, it could be that words compile or parse other words
on the fly, construct a mini program with it, and use it to
further modify the flow of execution.

I'm not saying we can't do this in other languages, anything
can be done in any language. Forth just makes it extremely easy.
Making something extremely easy is more enabling than it may
seem -- ask any Python programmer.

-marcel

hughag...@gmail.com

unread,
Dec 29, 2018, 10:10:20 PM12/29/18
to
On Saturday, December 29, 2018 at 11:53:12 AM UTC-7, hughag...@gmail.com wrote:
> Certainly, only advanced-level Forth programmers are qualified to write a book
> on intermediate-level Forth.
> When intermediate-level Forth programmers try to write a book, they invariably
> come up with yet-another novice-level book.
> When novice-level Forth programmers try to write a book, they invariably
> come up with a pile of nonsense (https://www.forth.com/forth-books/).

That webpage (https://www.forth.com/forth-books/) has this title:
"Forth Books by the Experts"
I really don't know why the ANS-Forth cult puts up with such gross arrogance.
Apparently they just don't have any pride.
Certainly, when sales-people are considered to be experts, there is no future.

Here is a fun quote from the self-proclaimed "expert" at Forth Inc.:

On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;

This code is really below novice-level.
Her array definer is limited to cell-size elements.
If she needs another size of element, such as for an array of floats,
she would copy-and-paste the array definer, tweaking it for the new element size.

Also, her COBOL background is showing through.
She has the bottom element indexed by 1 rather than by 0.

Note that this is the only example I am aware of in which Elizabeth Rather
wrote code herself from scratch.
Normally she posts code snippets copied directly out of "Starting Forth."
Her ARRAY is almost the same as the "Starting Forth" array but slightly tweaked
to provide range-checking, and screwed up with the lower index being 1.

Here is another example Elizabeth Rather gives of code from her book:
"Forth Application Techniques."
This STARS code-snippet is actually from: "Starting Forth."

On Friday, September 20, 2013 at 8:52:47 PM UTC-7, Elizabeth D. Rather wrote:
> Chuck basically invented stack comments, and insisted on
> their use when he was doing applications. FORTH, Inc. requires them, and
> the best programmers I've worked with for many years (alas, I haven't
> worked with Chuck since 1982) always include stack comments.
>
> For learners, stack comments are especially helpful, since by having to
> state them at the beginning of the definition they're led to focus on
> the stack going in and coming out, and the comment is there to remind
> them. One of the early simple exercises in Forth Application Techniques
> involves printing out [n] stars, which many define as:
>
> : STARS ( n -- ) 0 DO ." * " LOOP DROP ;
>
> The ones who include the stack comment are far less likely to just type
> STARS without an argument or forget the DROP at the end. But the
> consequences of forgetting the number are also a good teaching moment. ;-)
>
> Cheers,
> Elizabeth

Notice that the code doesn't work. The DROP at the end causes a stack underflow.

Elizabeth Rather just makes the Forth community look stupid!
I could write a better book on Forth than anything Forth Inc. has provided.
Actually, anybody with one week of training in Forth could do this,
assuming that the person has a three-digit I.Q..

It is not really worth my time to write a book on Forth programming.
I am not aware of anybody in the English-speaking world
who would be interested in learning Forth.
I would write a book if I could get it translated into another language.
Russian, Japanese or Spanish are all reasonable choices.
There are intelligent people who speak those languages.
I think Forth Inc. has ruined Forth's reputation in the English-speaking world.
Forth may have a future elsewhere though.

dxf...@gmail.com

unread,
Dec 30, 2018, 7:43:49 PM12/30/18
to
On Saturday, December 29, 2018 at 1:51:35 PM UTC+11, hughag...@gmail.com wrote:
> On Friday, December 28, 2018 at 6:23:33 PM UTC-7, dxf...@gmail.com wrote:
> > Standards, which are there to
> > support the interests of the mega-forths, are similarly doomed.
>
> This makes no sense!
>
> 1.) The purpose of a standard is to allow programs and code-libraries to be portable between different compatible systems.
> For this to work, there obviously have to be more than one system in use.
> So a standard is more useful for multiple small systems, rather than a few "mega-Forths."

What 'standard' systems are there today - probably less than came
into being immediately after ANS. If there's any new blood here,
it's systems that aren't aligned to a Forth standard.

>
> 2.) Neither Forth Inc. nor MPE are mega-sized companies.
> They are both very small companies.
> Even small plumbing companies employ an order of magnitude more people,
> and make an order of magnitude more money.

I didn't say they were. What both have got are mega-forths
which they can't easily change and would have others implement,
right or wrong, via a standard to the extent they can each agree.
Vendors will always have the upper hand in a standard as they
can assert they have paying users to support. Your only choice
here is whether or not you accept what is being handed to you.

Anton Ertl

unread,
Dec 31, 2018, 1:08:27 PM12/31/18
to
alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>I agree wholeheartedly, but the ultimate glueware at this moment is
>micropython. Our niche has been taken.

Well, two days ago I listened to a talk by an employee of the
Micropython company (George Robotics)
<https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9648.html>,
and MicroPython is certainly trying to eat into that niche. One of
the early points she made is that MicroPython compiles on the target
and has a text interpreter (called REPL in the Lisp and Python
communities) for interactive work. But I did not find the rest of the
talk very threatening for Forth.

They offer their own boards, which may be a good approach to avoid
portability problems and also good for having a revenue stream.

And the Q&A part pretty much showed the limitations of MicroPython.
When asked about memory, she mentioned 128KB, when asked about speed,
she could not really decide what to say, talked quite a bit, mentioned
"100 times slower than C" once, and later mentioned "4 times", but
that speed is often not that important. When asked about ports to
AVR, she had to ask several times to repeat the name (I understood it
on first hearing, and I am not a microcontroller person).

My conclusion is that Micropython is a well-hyped language
implementation that is probably useful for teaching and to attract
Pythonheads to microcontrollers. For industrial usage, I guess it can
be useful for C projects that want some interactivity, but the cost in
RAM usage may be prohibitive for that role.

The overlap with Forth is relatively small: Forth does not offer
garbage collection and dynamic type-checking, MicroPython does not
offer speed and low memory consumption. Still, someone
marketing-minded might want to address the people who come to
microcontrollers thanks to the hype, and show them how much more one
can do on the same hardware with Forth. Most won't like Forth (too
strange, too uncivilized), but a few might convert.

- 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/

Manuel Rodriguez

unread,
Dec 31, 2018, 2:35:19 PM12/31/18
to
Am Montag, 31. Dezember 2018 19:08:27 UTC+1 schrieb Anton Ertl:
> <https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9648.html>,
> But I did not find the rest of the
> talk very threatening for Forth.

It's right, before this kind of talk nobody has to be in fear. It was a
boring lecture, and the English was not that good. But with the correct
host, the situation is changing. Here, Siraj Raval himself explains what
Python really is, “Introduction - Learn Python for Data Science #1”
https://www.youtube.com/watch?v=T5pRlIbr6gg This guy has the right
attitude, he is motivated and has an army of 1 million followers at
youtube.

Albert van der Horst

unread,
Dec 31, 2018, 2:55:29 PM12/31/18
to
In article <2018Dec3...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>I agree wholeheartedly, but the ultimate glueware at this moment is
>>micropython. Our niche has been taken.
>
<SNIP>
>
>My conclusion is that Micropython is a well-hyped language
>implementation that is probably useful for teaching and to attract
>Pythonheads to microcontrollers. For industrial usage, I guess it can
>be useful for C projects that want some interactivity, but the cost in
>RAM usage may be prohibitive for that role.

Surely it is well-hyped. I was not sold on the hype though,
I was sold on the small board I tried out.

>
>The overlap with Forth is relatively small: Forth does not offer
>garbage collection and dynamic type-checking, MicroPython does not
>offer speed and low memory consumption. Still, someone
>marketing-minded might want to address the people who come to
>microcontrollers thanks to the hype, and show them how much more one
>can do on the same hardware with Forth. Most won't like Forth (too
>strange, too uncivilized), but a few might convert.

Before long one can no longer live without gc and behaviour that
adapts to data types. Adding a Forth to a Micro python would allow
speed and flexibility. People are working on that. For the outside
world it would be python.

>
>- anton

Paul Rubin

unread,
Dec 31, 2018, 3:42:35 PM12/31/18
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> When asked about memory, she mentioned 128KB

MicroPython works ok on a BBC Micro:bit which has 256k of program flash
and 16k of ram, though they had to struggle to fit in that little ram.
It's reasonably comfortable with 32k of ram. 128k of program flash
sounds kind of minimal. The Adafruit Trinket M0 uses a ATSAMD21E18
(256k flash, 32k ram) which is a 2 euro MCU in quantity, and it's nice
to use. The 256k flash is enough for the Python interpreter
(CircuitPython, Adafruit's hardware-oriented fork of MicroPython), REPL,
FAT file system, some libraries, and some space for user code and files.
You just plug the board into a USB port and it appears as two devices
simultaneously: a USB flash disk (so you can drag and drop files to it)
and a USB serial port, so you can type to the REPL. It is really an
easy and friendly way to get started with microcontrollers.

MicroPython also works ok on the ESP8266: there's lots of 3-4 euro
boards that have the MCU (128k ram, mostly used by the wifi stack) and a
few MB of SPI flash. The fancier ESP32 costs a little more but has two
200MHz CPU cores and 520k of ram. But, I haven't tried it on any of
these.

> when asked about speed, she could not really decide what to say,
> talked quite a bit, mentioned "100 times slower than C" once, and
> later mentioned "4 times", but that speed is often not that important.

Like Forth, the speed difference will depend on what you're doing, but
in simple tests I've found MicroPython to be comparable to CPython. So
maybe 50x on average depending, compared to maybe 20x for threaded
Forth. Still not too bad imho.

> When asked about ports to AVR

If that means 8-bit AVR, it is not really feasible.

> For industrial usage, I guess it can be useful for C projects that
> want some interactivity, but the cost in RAM usage may be prohibitive
> for that role.

We're in an era where ram in kilobyte amounts costs almost nothing. Or
on even smaller parts, I think it's hard for Forth to compete
resource-wise with C, because of the memory used by Forth's stacks, the
higher inconvenience of using bytes instead of wider cells, program
space used by the interpreter and extraneous Forth word definitions,
etc. Maybe there are Forth compilers that can target an 8-bit MCU with
0.5k of program flash and 32 bytes of ram, but (like C) they will be
external compilers that don't bring much interactivity to the target app
either.

> The overlap with Forth is relatively small: Forth does not offer
> garbage collection and dynamic type-checking, MicroPython does not
> offer speed and low memory consumption.

On workstations and servers I've found it best to think of Python as a
scripting wrapper for a bunch of C libraries, so the pure interpreter's
speed is not that important even for cpu-heavy tasks. For example,
Python is a favorite for numerical computation and machine learning
because of Numpy (a numerical linear algebra package, more or less) and
interfaces for libraries like Tensorflow. Your application just doesn't
spend much time in Python itself. It's also easy to write C extensions
for CPython if you have to speed up some bottleneck. I haven't tried
extending MicroPython but I believe it's similar.

I'd expect interpreted MicroPython on today's 3 dollar Cortex-M to be at
least as fast as threaded Forth on yesteryear's 3 dollar 8-bitter. That
does leave the issue of much larger ram consumption and possible GC
pauses interfering with realtime response. Whether that matters will be
application specific. I think the ESP8266 implementation may run the
MicroPython interpreter as a task under some kind of RTOS, so that it
can be preempted by the wifi stuff.

Once you're at the level of an industrial device (not battery powered)
you might as well use an embedded Linux board (starting at the 5 dollar
Raspberry Pi Zero) and then have basically unlimited resources and
software options.

> Still, someone marketing-minded might want to address the people who
> come to microcontrollers thanks to the hype, and show them how much
> more one can do on the same hardware with Forth.

It would be a lot of work to do even the same things on the same
hardware. E.g. ESP8266 MicroPython apparently has good integration with
the ESP8266 wifi stack. You'd have to do the same thing for Forth, and
then deal with the increased pain of writing network applications in
Forth, protecting them from malicious input causing buffer overflows,
and all that sort of thing.

I agree it would be nice if someone sold cheap MCU boards with a nice
Forth system already on them, so you could just plug one into a USB port
and start typing Forth commands. Jurgen Pintaske's 4e4th board was
along those lines.

Paul Rubin

unread,
Dec 31, 2018, 4:00:46 PM12/31/18
to
alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> Surely it is well-hyped. I was not sold on the hype though,
> I was sold on the small board I tried out.

You have a lolin32 right? How do you like it? Do you use the bluetooth
from micropython and does it work? I found the esp32 hardware to be
very exciting, but didn't buy an early one because the software was then
supposedly not really complete. I don't know the current state of it.
I know the Adafruit esp32 pages still have a disclaimer about the
software.

Anton Ertl

unread,
Jan 1, 2019, 5:44:09 AM1/1/19
to
Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> When asked about memory, she mentioned 128KB
>
>MicroPython works ok on a BBC Micro:bit which has 256k of program flash
>and 16k of ram, though they had to struggle to fit in that little ram.
>It's reasonably comfortable with 32k of ram. 128k of program flash
>sounds kind of minimal. The Adafruit Trinket M0 uses a ATSAMD21E18
>(256k flash, 32k ram) which is a 2 euro MCU in quantity, and it's nice
>to use. The 256k flash is enough for the Python interpreter
>(CircuitPython, Adafruit's hardware-oriented fork of MicroPython), REPL,
>FAT file system, some libraries, and some space for user code and files.
...
>Like Forth, the speed difference will depend on what you're doing, but
>in simple tests I've found MicroPython to be comparable to CPython. So
>maybe 50x on average depending, compared to maybe 20x for threaded
>Forth.

Last time I measured threaded-code Forth systems (on a 486, but then
the performance characteristics of embedded CPUs are more like that of
a 486 than a current desktop CPU), the slowdown compared to hand-coded
C was 3.77-7.22 for Gforth (in 2000, so Gforth ~0.5.0), 6.62-11.18 for
Win32Forth, and 5.32-12.63 for eforth. Data from
<http://git.savannah.gnu.org/cgit/gforth.git/plain/timings.sc?id=495fd3359331c1db8d1f7f6719e00bc7f62b40f8>.

Also, with Forth you are not limited to threaded code. There are a
number of native-code Forths that work on embedded controllers, both
from commercial vendors and as free software (e.g., Mecrisp).

>If that means 8-bit AVR, it is not really feasible.

Forth is.

>We're in an era where ram in kilobyte amounts costs almost nothing.

For some reason that does not seem to be true for microcontrollers.

>Or
>on even smaller parts, I think it's hard for Forth to compete
>resource-wise with C, because of the memory used by Forth's stacks,

C uses a stack, too, and typically more. What gives?

>the
>higher inconvenience of using bytes instead of wider cells,

Forth can use bytes or wider cells, as needed. What gives?

>program
>space used by the interpreter and extraneous Forth word definitions,
>etc. Maybe there are Forth compilers that can target an 8-bit MCU with
>0.5k of program flash and 32 bytes of ram, but (like C) they will be
>external compilers that don't bring much interactivity to the target app
>either.

I don't know if there are Forth systems for these sizes (or if there
are microcontrollers for them), but there is a lot of room between
0.5KB flash and 256KB, and between 32 bytes of RAM and 16KB.

Mecrisp, a native-code system with the compiler on the target fits
into 11KB flash and 512 bytes RAM on an MSP430, 16KB flash and 1KB RAM
on ARM (Mecrisp-Stellaris).

And then there are systems where the compiler is on the host, and yet
they are interactive. Forth, Inc. calls this "tethered", while MPE
calls this "umbilical". <https://www.forth.com/embedded/> gives an
example where the system functions take 5582 bytes program (flash?)
and 766 bytes data (RAM) on a 16-bit CPU.

Interestingly, AFAIK only commercial systems went there. Either this
technology is too much work, or not fascinating enough for a
spare-time project.

>I'd expect interpreted MicroPython on today's 3 dollar Cortex-M to be at
>least as fast as threaded Forth on yesteryear's 3 dollar 8-bitter.

Maybe, but why would that be relevant? Forth on today's $3
microcontroller is faster, and moreover, it also runs on the 8-bitter,
which costs less today.

>It would be a lot of work to do even the same things on the same
>hardware. E.g. ESP8266 MicroPython apparently has good integration with
>the ESP8266 wifi stack. You'd have to do the same thing for Forth, and
>then deal with the increased pain of writing network applications in
>Forth, protecting them from malicious input causing buffer overflows,
>and all that sort of thing.

Well, given that MicroPython's answer to the performance question (and
many others) is "C", MicroPython has the same problems; probably more,
because C has idioms such as strcpy() that encourage such problems.

Albert van der Horst

unread,
Jan 1, 2019, 7:31:36 AM1/1/19
to
In article <877efp5...@nightsong.com>,
I tried out the wifi stuff. Could see as much networks as on my
tablet with a few Python commands and was impressed. I've
not done much more with the board lately, can you guess why?

Groetjes Albert

Paul Rubin

unread,
Jan 1, 2019, 7:41:17 PM1/1/19
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> a 486 than a current desktop CPU), the slowdown compared to hand-coded
> C was 3.77-7.22 for Gforth (in 2000, so Gforth ~0.5.0), 6.62-11.18 for
> Win32Forth, and 5.32-12.63 for eforth.

That eforth figure is pretty good, better than I'd have expected.

Note that MicroPython by default includes bignum arithmetic (it is
disabled in CircuitPython). I don't know if that affects the speed
much. But my MicroPython timings have it enabled. I might try building
and timing MicroPython with bignums turned off.

>>Or on even smaller parts, I think it's hard for Forth to compete
>>resource-wise with C, because of the memory used by Forth's stacks,
> C uses a stack, too, and typically more. What gives?

C doesn't use a data stack, and isn't interactive, so the compiler
and/or programmer can statically figure out how space the hardware stack
needs, and the compiler can put function locals and intermediate results
in registers. With interactive, interpreted Forth you need enough space
to accomodate the data and return stack space that the programmer MIGHT
want to use, and they normally both have to go in memory.

> Forth can use bytes or wider cells, as needed. What gives?

I don't think Forths with 8-bit cells have gotten much traction. Most
use 16 or 32 bit cells. So you do use 2x or 4x the memory for 8-bit
intermediate results. Yes you can do byte memory operations but that is
slightly contorted.

> I don't know if there are Forth systems for these sizes (or if there
> are microcontrollers for them), but there is a lot of room between
> 0.5KB flash and 256KB, and between 32 bytes of RAM and 16KB.

It seems to me that Forth isn't really practical with less than maybe
0.5k of ram. Going in 64x increments you can basically classify ram as:
1) tiny (under 0.5k); 2) small (0.5k to 32k); 3) medium (32k to 2 meg);
and 4) large (above 2 meg).

The natural tools to use at those sizes look to me like 1) C or
assembler; 2) Forth; 3) MicroPython etc.; 4) "big" Python, embedded
Linux etc.

So Forth is attractive in just one layer of that cake, and that layer is
getting (economically) thinner all the time.

> <https://www.forth.com/embedded/> gives an example where the system
> functions take 5582 bytes program (flash?) and 766 bytes data (RAM)
> on a 16-bit CPU. Interestingly, AFAIK only commercial systems went
> there. Either this technology is too much work, or not fascinating
> enough for a spare-time project.

I've found it interesting and started writing something like it for STM8
last year, but had to put it aside because of something urgent that came
up then. I might get back to it sometime. It was not going to be
anywhere near as fancy as the commercial systems. The host side is
written in Python and the target side in C. The target side code is
about 2k bytes compiled with SDCC.

>>I'd expect interpreted MicroPython on today's 3 dollar Cortex-M to be at
>>least as fast as threaded Forth on yesteryear's 3 dollar 8-bitter.
>
> Maybe, but why would that be relevant? Forth on today's $3
> microcontroller is faster, and moreover, it also runs on the 8-bitter,
> which costs less today.

If a hobbyist or prototype engineer making a one-off gadget can save
development time by using a $3 32-bitter with 32k ram instead of a $1
8-bitter with 0.5k, they will pay the extra $2 to save the time. If a
product designer making something that will ship in high quantity can
spend extra time to use a 50-cent 8-bitter with 64 bytes of ram instead
of a $1 8-bitter with 0.5k, they will spend the time to save the 50
cents * N units. This is what I mean about Forth's layer getting
thinner.

> Well, given that MicroPython's answer to the performance question (and
> many others) is "C", MicroPython has the same problems; probably more,
> because C has idioms such as strcpy() that encourage such problems.

Since the dawn of Forth, Forth's answer to the performance problem has
been "assembler", to the point where traditional Forths had built-in
assemblers and CODE words. Optimizing Forth compilers competitive with
C arrived fairly recently Forth's history. They do change the picture
somewhat though.

Actually it looks like micropython can generate native code for more
speed at the expense of code space, and optionally giving up bignums:

http://docs.micropython.org/en/latest/reference/speed_python.html#the-native-code-emitter

a...@littlepinkcloud.invalid

unread,
Jan 2, 2019, 6:30:24 AM1/2/19
to
Paul Rubin <no.e...@nospam.invalid> wrote:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
> We're in an era where ram in kilobyte amounts costs almost nothing.
> Or on even smaller parts, I think it's hard for Forth to compete
> resource-wise with C, because of the memory used by Forth's stacks,

I know there are some C compilers that statically allocate everything
based on whole-program analysis, but I don't know of any that are
effective on tiny MCUs that are too small for Forth. Apart from
anything else, if you're constrained for code space you'll want to use
something like byte-token-threading, and that's easy in Forth.

> the higher inconvenience of using bytes instead of wider cells,
> program space used by the interpreter and extraneous Forth word
> definitions, etc. Maybe there are Forth compilers that can target
> an 8-bit MCU with 0.5k of program flash and 32 bytes of ram, but
> (like C) they will be external compilers that don't bring much
> interactivity to the target app either.

Interactivity on very small devices has been a solved problem in Forth
for some 30 years, ever since talker PROMs and then chipFORTH. 0.5k of
program space is tight, though. For Forth, especially if you want
multi-tasking, I think that a reasonable minimum is 128-256 bytes of
RAM and 4k program space.

> Once you're at the level of an industrial device (not battery
> powered) you might as well use an embedded Linux board (starting at
> the 5 dollar Raspberry Pi Zero) and then have basically unlimited
> resources and software options.

Not necessarily. If you have a very small MCU that is controlling
something, you're quite likely to be at the sharp end of real
time.

Andrew.
Reply all
Reply to author
Forward
0 new messages