I just stumbled over this bare-metal Forth on RPI, pijFORTHos (https://github.com/organix/pijFORTHos), which I'd like to recommend to a more general group of Forthwrights because it contains the brilliantly commented syntax of its x86 parent: https://github.com/organix/pijFORTHos/b ... orth.s.txt . Its a model implementation of a DTC Forth with lots of cute ASCII drawings. That is the link to the assembler core, the higher-level words are here: https://github.com/organix/pijFORTHos/b ... orth.f.txt

I can't be 100% sure, Scot, because x86 assembly and ARM assembly both give me a headache, but it looks like those implementations to which you linked are ITC rather than DTC, based on what looks like a raw address in each CFA instead of raw machine code in each CFA, the latter of which is one of the defining characteristics of DTC. In other words, a DTC secondary's CFA would contain a "JSR DOCOL" instead of a "DW DOCOL", according to my limited understanding.

I agree with you that the plain English commenting is superb, but I find the paucity of stack comments in the x86 version to be an issue, at least for the primitives in the .s file.

Mike B.

Ah. Good point, I admit I just trusted the paragraph headline in the assembler file. I hope I can spend more time with the code this week, will try to figure that out.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

In the time since Fox published his essay, computing power in the x86-64 arena has greatly increased, even as the cost per MIPS has plummeted. This tends to reduce the performance arguments in favor of Forth, especially if Linux is considered (Linux was not mentioned in Fox's essay). The Linux kernel has been almost continuously massaged to make it perform with maximum alacrity and stability. Hence the only really viable area for Forth these days is in systems lacking copious amounts of computing power and resources.

The reality is Forth remains a niche environment that doesn't fit well with many common computing tasks. Your average, non-technical computer user is not going to look at an environment that is RPN-based and can be made to self-destruct through simple mistakes. I've been using and programming computers of one sort or another since the latter 1960s and while I've read about and understand the basics of Forth, I have yet to encounter any good reason to invest time in it. When I'm a computer user, as opposed to a programmer, I want to be able to, using an automotive analogy, drive the car without having to first put it together. That's not Forth. If I'm a computer programmer, I necessarily have to develop in the language that will suit the task. That usually won't be Forth, since most of my professional programming is for clients who are not and never will be running Forth.

Forth is great for geeks and nerds, and terrible for the rest of the computing population. Or, to borrow a phrase posted by someone else around here, Forth got voted off the island years ago.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I sense a twinkle in your eye, BDD, as you must surely be aware that your post is provocative.

I haven't read Jeff Fox's article, and I don't necessarily defend all claims made by him regarding Forth. It's possible he stated his case too zealously. Talk to him about that. What I will say is that Forth's interactivity makes it extremely fast to develop code with, and this boon doesn't come at the cost of sluggish performance or bloated memory consumption.

And yet you're willing to write in assembly? -- a language that can be made to self-destruct through simple mistakes?

You don't seem to recognize that your clients could run Forth and be unaware that they're doing so, just as they could run code written in C or BASIC without being aware. And the code could run under Linux.

IMO it's clear your grasp of Forth basics is incomplete. To be fair, even a large amount of reading may not be enough. You have to spend some time in the driver's seat (using the automotive analogy).

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Sadly, Mr. Fox is no longer with us. A heart attack took his life in 2011.

http://www.legacy.com/obituaries/sfgate ... =151440780

Mike B.

Not intentionally so. I'm merely stating perceptions and to some extent, reality. Outside of 6502.org, I have seen very little enthusiasm for Forth. As I said, most non-technical computer users are not going to be enamored with an operating environment that works against conventional thinking, e.g., postfix vs. infix notation. Postfix may be great for the computer, but is contrary to how people process numbers. It's very tough to fight that kind of intellectual inertia.


That is true, but is hardly unique to Forth. I can recall working on systems in the 1970s in which the entire machine had only 128K (no bloated memory consumption) and could support 16 concurrent users in full conversational mode, making it quite interactive. The primary performance constraints in those systems were related to I/O bound activity, which would have been a constant no matter the chosen operating environment.


In the case of developing firmware for a computer, assembly language is close to being de rigeuer. That it is possible to crash the machine with simple mistakes is a known weakness of assembly language—my clients are not going to be working at that level. In developing for clients, C is as low-level as I usually get, which while containing a variety of linguistic booby traps, isn't going to crash the machine when a program bug is encountered.


Forth lacks the functionality required to process many business applications. Yes, functions can be developed to plug such gaps, but at what expense in terms of development time?


That I would do if there was something to be gained from it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It takes a lot of experience in Forth to truly grasp how much capability is there.  One cannot make a valid judgment from the outside.  It is common for even newish Forth enthusiasts to think there are certain things Forth would not be able to do well or even at all; but as they gain experience, they find that not only can it do them, but offers very elegant solutions for them.  It happened to me, and it still continues to, even after 25 years.  Those solutions tend to be non-obvious, because instead of being canned and advertised or even put in a manual, it's just that the tools are there waiting for you to do things with them that perhaps no one else has done.  There's a flexibility there that I have not seen in any other language.

Regarding applications, Jeff Fox does say in the essay,

no single operating system or programming language is ideal over the whole range of machines and application domains

so he's not being naïve in his enthusiasm; but he does speak from a ton of experience in programming and Forth hardware.

I would add that what "conventional thinking" is (the postfix vs. infix notation thing) may depend on the individual.  I much prefer postfix and using a data stack and getting rid of the piles of parentheses.  I understand that the Korean language is post-fix, so Koreans tend to pick up Forth more naturally than Americans do.  English is my first speaking language, but not the first language I learned to read and write in.  (Spanish is.)  That may have some influence on my thinking.  In someone's musings (name withheld to protect the guilty) on language implementations on the 6502, he says that errors in data-stack manipulation are a serious problem in Forth.  This shows his inexperience with it.  Actually, you could write an infix parser in Forth, but I've never heard of anyone wanting to after they come up to speed in Forth.  As for crashes, I very seldom get a crash when developing software in Forth, and when I do, I can usually recover in a couple of seconds, without re-loading software, and I usually realize right away what I did wrong.  No debuggers, etc. needed.

Forth has run entire hospitals and airports with all their business and administrative tasks; so I don't think there's any shortage of capability for business applications.  Forth, Inc. offers their SwitfForth which includes object-oriented programming and all the tools to integrate with Windows, Linux, and Mac OS X.  Please see https://www.forth.com/swiftforth/ .

Regarding development speed, a quote from Jeff Fox's essay which I've seen corroborated in Forth, Inc.'s literature:

We have many examples where the smaller team of Forth programmers finished the project much faster than the larger team of 'C' programmers.  The typical ratio in required man-months is about ten to one.

I know Samuel Falvo has said it doesn't have to be that way, but it is common.

Regarding run speed, memory required, and power taken, Jeff Fox says:

There are also many examples where the resultant code generated in 'C' was simply too slow or too big or too power hungry to meet the application requirements and where Forth came to the rescue.

It doesn't have to be just Forth though.  My assembly-language techniques, productivity, and enjoyment have benefited a ton from my Forth experience.  I know I should read the book "Thinking Forth" again as it is really about programing philosophy; and although it's Forth-centric, many of the principles in it can be carried into other languages as well.

Regarding "using an automotive analogy, drive the car without having to first put it together," yes, that has been a problem in the '02 Forth world.  I have a pipe dream of porting my Forth (which is far more extensive than FIG's) to someone's SBC they're selling and making a turnkey system that gives results right out of the box.  This does exist for PCs though, reference again Forth, Inc.'s SwiftForth.

Quote:

Sadly, Mr. Fox is no longer with us.  A heart attack took his life in 2011.

yes, sad news

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

... and is now currently in orbit around Saturn in the Cassini Probe (see http://lasp.colorado.edu/~horanyi/gradu ... g_MIMI.pdf for details) ... but yes, in the age of majorly overpowered hardware, it is hard to justify Forth for the mainstream.

Forth's strengths should be found, I think, in severely constrained systems.

Another possible advantage is in learning: does Forth illuminate aspects of computer science which are interesting, which are not illuminated by other languages? I think so. It can show us something about how computation can be organised. That doesn't mean it's necessarily a good first language, of course, and I suspect it isn't.

Another aspect of a programming language is its suitability as an engineering tool - and for that, I'd be interested to hear informed opinions: particularly, has anyone ever had experience in a team environment, writing Forth to solve a problem and needing to maintain the solution over time? (Let's take three people as the minimum team size for this purpose.)

I can confirm this. For some reason those forums seems to be a nest of FORTH enthusiasts, but outside of here... virtually nobody seems to be interest. Not saying that's good/bad or whathever, just notice how things happens to be.


In other words, the learning curve is very high, which is usually a bad sign.


This is a false debate, because only a very small part of a computer program is actually made of mathematical formulas.


So this is a biased propaganda.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That's absolutely irrelevant to whether or not Forth is useful (or even useable).

Nothing worth learning (or at least, nothing that brings above-average returns) is simple.

The use of the stack is not restricted to mathematical formulas... the stack is used for setting up function parameters, too. The main difference to "conventional" languages is that the stack operations are explicit in Forth.

Biased in a good way, surely? In the last few posts in this thread the arguments for Forth have come from people who have made the investment of learning Forth and used it, while the arguments against it seems to have come from people who have decided that learning Forth is not worth the effort.

I am neither for or against any language, including Forth. I was just pointing out it's usage outside of this forum is extremely marginal, which do not mean the language is any better or worse than anyother.

I learned the basics of Forth because enthusiasts on 6502.org convincted me to do so, and yet I still don't know what to do with that knowledge. I just learned the basics, knowing how to deal with the stack is great and all, but not sufficient for an actual computer program, where concepts such as arrays, structure, memory allocation and strings comes very early and are not natively implemented in Forth, meaning you have to implement your own (which is probably not complicated but still). I think the major reason I wasn't able to get further is that the books I found sucked. I really hope I'll be able to continue and write actual program in Forth however, after I find a good book.


WHAT ?
I think that, 1. everything is worth learning and 2. particularly if it's simple, since it makes the learning process faster.

The understanding I had of Forth is that the language itself is extremely bare-bones, but it is extremely extensible to compensate for that, and allow you to do very complicated things with a few "words". This is nothing special as any program that supports function (a.k.a. subroutines or procedures) can do that, but the way it is syntaxed and factored out with words is more elegant, and I like the concept. Again the only reason I didn't went further is the lack of decent learning material offline, and the fact there was no immediate need for it.