Forth

The one that you write for yourself?

Would that I could!

Interesting suggestion at elinux.org/forth. Also, searching for 'raspberry pi forth', I find several mentions of bare metal implementations.

IMHO where Forth falls down it is because it is a write-only language; programs other than the limited training exercises being difficult to fathom out.

Taking an analogy with the building trades, it is very easy to understand the simple operation of laying bricks, but were you to attempt building a hospital by laying a few bricks without sight of the complete project, you'd very soon end up with little more than a pile of bricks.

If you're starting out, I recommend that you take Python in your stride; there's a very goo book about Python for the RPi

(Sorry if I'm teaching you to suck eggs)

I know Python 2 (I'm not sure how different Python 3 is) but I want to play with Forth just for the fun of it.

There's rpiForth but is it moribund?

Without knowing what you know, its hard to know what to suggest, but here goes....

I last played with Forth in the early/mid '80s, running it under FLEX09 on a 6809-based system. On mosing round that, I discovered that Forth is very easy to port because there's almost no machine-specific code in it. In this case, the loaded file's entry point pointed to a single JMP instruction that that started the first Forth word running. The first

10-20 words contained assembler - probably no more than 100 instructions in total. These were enough to start its builtin Forth compiler which compiled the rest of the runtime words (all written in Forth) and ran them, initialising the system and ended up by outputting a greeting line and a command prompt. So, if you know ARM assembler, porting it yourself should be quite easy.

That said, I think you could do worse that trying pForth -

This claims to be fully portable because its low-level words and startup code are written in C. It has a number of precompiled downloads, including one for the RPi. It looks as though you're supposed to pull the source from Git and compile it on your RPi.

Try some of the links here if you don't like the sound of pForth:

raspberry-pi

Baremetal implementations may not be what you want, since they should be exactly that: no OS, no filing system - just an SD card that boots directly into Forth and (if its a really traditional Forth implementation), treats the part of the SD card that is not occupied by the Forth boot image as an array of 1KB pages. These pages are numbered and are used by Forth as its filing system. A page may contain (part of) a Forth program or data to be read or written by a Forth program and all are addressed by page number.

Have fun!

--
Martin    | martin at 
Gregorie  | gregorie dot org

Hello Stephen!

28 Jun 18 10:30, you wrote to headstone255.but.not.these.five.wo:

SP> Writing readable code is something that has to be learned. I speak SP> as someone involved in the maintenance and development of a SP> Forth application of 1,400,000 lines of source code.

You should have been fired, when the count reached 1000 lines.

Kees

Hello Stephen!

28 Jun 18 14:39, you wrote to All:

SP> Then the team should have been fired 20+ years ago. When I first met SP> this app 20 years ago, it was already over 500,000 lines.

SP> On your thought basis, virtually every FOSS tool in the business, SP> including gcc should self-destruct immediately.

I know Dos and windows made a lot of money as well. ;)

Kees

define best

--
There is much Obi-Wan did not tell you. 
		-- Darth Vader

An actual FORTH 'kernel' is very easy to write.

But then it has a lot of 'library' to make.

--
To ban Christmas, simply give turkeys the vote.

Well to hell with 'best' just tryu one and see if it works.

I ported FORTH to an 80186 embedded processor once.

Its huge fun.

--
To ban Christmas, simply give turkeys the vote.

Loeliger's (sp?) book, Writing Threaded Interpretive Languages is a very good explanation.

Out of print, but available via Abebooks.co.uk

+1

There are plenty of free Forths of varying qualities. The most substantial of these is probably GForth.

If you are prepared to pay for one, MPE's VFX Forth for ARM Linux is a modern high-performance Forth that compiles direct to native ARM code. There will be a free version of this released for non-commercial use during summer 2018.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441 
web: http://www.mpeforth.com - free VFX Forth downloads

This is a traditional calumny. Bad programmers write bad code. A problem with Forth is that you need to be quite a good programmer to use it well.

Writing readable code is something that has to be learned. I speak as someone involved in the maintenance and development of a Forth application of 1,400,000 lines of source code.

That's engineering. It applies to all programming languages.

The idea that you only need one or two languages for daily use is relatively recent. When I started programming for a living we used several a year because the salesmen kept giving compilers away in order to sell hardware. Programming is a discipline and a craft. It needs practice.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441 
web: http://www.mpeforth.com - free VFX Forth downloads

No it is not. It is true. Forth is a favourite of badly or self taught programmers because on the surface it seems very easy to get started, and, although aficionados of FORTH will understand and remember everything that they themselves have coded, the same is not true for the unfortunate individuals who have to maintain the code; maintenance being where most of the cost of software lies. This is because FORTH is more an assembly language than a high level language. Indeed, the instruction set of the English Electric KDF9 is remarkably similar, and its publication may well have been the inspiration for Charles Moore, the instigator of FORTH.

True in all languages, and FORTH is a field where self taught programmers feature largely as bad ones.

It is unclear from that comment whether or not you disagree with me.

But it cannot be learned in FORTH; FORTH being in Reverse Polish Notation.

An example, take the general snippet of A + B, or, A+B, which in FORTH becomes A B +, and NEVER AB+ because spaces are very important in FORTH to separate the verbs.

In a HLL, were you to code A + + B (deliberately spaced to circumvent indignant C programmers :-) ) it would get thrown out as a syntax error, but in FORTH were you to code A B + +, it would compile OK, but you wouldn't find your error until your program crashes. Hence, more an assembly language than a HLL.

I bet you're the only person who knows their way around that cod.e

FORTH is great for hacking, for perhaps implementing the on-boot monitor for new processors without other support, but the very nature of FORTH indicates that it is not engineering, for, were you to be involved in the many weeks, months even, of designing a large software project, you would not be writing it in FORTH, even assuming you could assemble a team of FORTH experts.

Straw Man / Non sequitur.

Rapid flitting between languages over the course of a year suggests lightweight applications.

A truism, but by asserting that you seem to suggest that the practice needed for FORTH is so much greater than for other languages and environments.

Just my Ha'pporth, IMHO YMMV

This is just proof by repeated assertion. What qualifies you to make these assertions? I have run a Forth software shop since 1981, so on a did/didn't basis, I've seen a lot of Forth code. As an embedded systems rogrammer, I've seen a huge amount of bad C code and bad code in a range of languages.

If you don't know how to use a language, you will write bad code in it. Forth is a remarkably subtle language.

There are no write-only languages, with the possible exceptions of Brainfuck and Mondrian.

You call Forth an assembly language. I call it an extensible language. Good Forth programmers use the extensibility.

Ah, the data stack. It's easy to blame the combination of RPN and an untyped language. These are beginner problems that are not considered an issue by experienced Forth programmers. If you can't cope with a stack, you'll never be a good programmer.

Rubbish. It's a team effort by one of our clients.

Your repetition is tedious. The app with 1,400,000 lines of source code is now nearly 30 years old and has made the company a lot of money. There are other Forth apps, ancient and modern, that have performed extremely well over long periods.

It was fashionable to rubbish Forth until a few years ago, when I observed that the senior technical people of many progressive companies have fond memories of Forth. Yes, it's not fashionable, but it works in the right hands. It's not for everyone.

It needs a professional tool chain of the sort supplied by MPE and Forth Inc. The free toolchains simply do not cut it for serious applications.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441 
web: http://www.mpeforth.com - free VFX Forth downloads

A concatenative language. I've played with forth in the past. I've recently been playing with factor which is also a concatenative stack based language.

--
Andy Leighton => andyl@azaal.plus.com 
"We demand rigidly defined areas of doubt and uncertainty!" 
   - Douglas Adams