Forth - How many know about and use it?

[helius]

All the words are "RPN" if that means that you can write their stack effect (which you can for all words). Sometimes it will be a "compiling" stack effect with words taken from the parser stack (as with VARIABLE), but I'll argue that's still RPN.

The system is powerful. You can put hooks on defered words, redefining what they do at runtime. This can be very convenient and is one of the real elegant things about OpenBoot/OpenFirmware.

[rfclown]

I have never used Forth why?

The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.

Today's youth. Thinking Python/RPi stuff is efficient embedded stuff.

I worked at a company where the embeded guy (a contractor) used FORTH. It was a medical product (neurostimulator). When he retired the company found another FORTH programmer to continue the work. While the new guy was very good, and I would recommend him to anyone (Leon Wagner of FORTH Inc), it troubled me that if we lost him, it might not be easy to replace him. If it was my company, I would have chosen to use C initialy, mainly for the ease in finding/replacing programmers. I looked at FORTH, but I'm put off with the readability of the code. I can write C in a way that I can come back years later and figure out what I did. I couldn't even get started with FORTH without pondering every line. Maybe I'm just dull. It seems to be very efficient resource wise.

FORTH was the first high level language written for the RCA 1802 (COSMAC), and was done by the programmer I know. The 1802 was used in some spacecraft like Galileo and Magellan. They are sparce with resources on spacecraft (no Python there).

I recently ran across a cool project where someone made a computer out of logic chips (no processor) that ran FORTH.
http://www.aholme.co.uk/Mk1/Architecture.htm

[gnuarm]

All the words are "RPN" if that means that you can write their stack effect (which you can for all words). Sometimes it will be a "compiling" stack effect with words taken from the parser stack (as with VARIABLE), but I'll argue that's still RPN.

I don't know if it is worth arguing nomenclature, but some things in Forth are not RPN.  Maybe VALUE is not the best example.  The part of VALUE that is not RPN is reading the name of the value item from the input stream following the word VALUE.  That is like any other compiled language. 

3 VALUE Three

creates a new word initializing the value to 3.   As you can see the name is not on the stack when the word VALUE is encountered.  There are words that operate on strings with their descriptors on the stack as address and length.  Other types of strings are counted with the count appearing as the first item in the array.  These work with the stack. 

String definitions are not RPN themselves.  Declaring a string is read from the input after the word that starts it.

." string contents"


Assemblers written in Forth are a good example.  Early Forth assemblers had very different assembly syntax to be easier to write.  They would appear as

opr1 opr2 opcode ,

The operands were words that returned the register id for example and the opcode was a word that accepted the two operands from the stack and combined them with the numeric opcode to produce the instruction on the stack.  The comma is a Forth word to put the word from the stack into the dictionary which is where the code would be compiled for the time being. 

Now the non-RPN assemblers written in Forth use the same syntax as any other tool (for the opcode and operands anyway), but the various aspects of using commas and such are different.  Still, they are no longer RPN. 

While it is not really hard to get used to RPN, many don't like it (the lazy ones perhaps?) and many Forthers are willing to accommodate that.

The system is powerful. You can put hooks on defered words, redefining what they do at runtime. This can be very convenient and is one of the real elegant things about OpenBoot/OpenFirmware.

Yes, I've used that to redirect I/O between the console for debugging and a serial port for runtime work or even a socket connection to another window. 

One of the issues that people don't like is that many things are only provided in a raw form.  You often have to do a fair amount of work to create your own libraries.  Compared to the many libraries that can be found for many languages that would appear to be inconvenient.  But I view all but the most often used libraries with a cautious eye.  They are like footprint libraries for layout.  The footprints may be fine, but if they have a bug I don't want to find out after they are used in a design.  So I create my own footprints and I tend to write my own libraries.

[gnuarm]

I have never used Forth why?

The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.

Today's youth. Thinking Python/RPi stuff is efficient embedded stuff.

When you have MB of memory Forth's size advantage is not so important.

I worked at a company where the embeded guy (a contractor) used FORTH. It was a medical product (neurostimulator). When he retired the company found another FORTH programmer to continue the work. While the new guy was very good, and I would recommend him to anyone (Leon Wagner of FORTH Inc), it troubled me that if we lost him, it might not be easy to replace him. If it was my company, I would have chosen to use C initialy, mainly for the ease in finding/replacing programmers. I looked at FORTH, but I'm put off with the readability of the code. I can write C in a way that I can come back years later and figure out what I did. I couldn't even get started with FORTH without pondering every line. Maybe I'm just dull. It seems to be very efficient resource wise.

From his reputation, Leon Wagner would be hard to replace, but I'm not sure you'd really need someone of his skill level to do most programming. 

This is one reason why people aren't interested in Forth.  I get the same argument against using FPGAs.  Lots more C programmers than HDL. 

FORTH was the first high level language written for the RCA 1802 (COSMAC), and was done by the programmer I know. The 1802 was used in some spacecraft like Galileo and Magellan. They are sparce with resources on spacecraft (no Python there).

Yeah, Forth was used on one of the asteroid landers, the name escapes me at the moment.  In space stuff what is most important is that the tools be qualified as well as the hardware.  That's an expensive process, so they tend to continue using things for a long time. 

I recently ran across a cool project where someone made a computer out of logic chips (no processor) that ran FORTH.
http://www.aholme.co.uk/Mk1/Architecture.htm

Yeah, using discrete SSI components is not so common, but stack processors on FPGAs are very common.  I've done some myself.  I think it was a confluence around 2000 when FPGAs started being big enough and a lot cheaper so the idea of a CPU on the FPGA wasn't so crazy.  A stack processor can be very small and fast. 

[retiredfeline]

There is an active project putting Forth in off the shelf STM8 based gadgets: https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets

I know about Forth, even have books on it from decades ago, and have wanted for a long time to play with it, not so much for the small footprint (costs very little to buy a uC with more memory), but the interactive nature of coding and debugging. Maybe I'll get a round tuit one day.

[DiTBho]

It may not be perfect, but Forth may be implemented on my graphic pocket calculator in order to interactively manage the sensor-port 

[gnuarm]

There is an active project putting Forth in off the shelf STM8 based gadgets: https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets

I know about Forth, even have books on it from decades ago, and have wanted for a long time to play with it, not so much for the small footprint (costs very little to buy a uC with more memory), but the interactive nature of coding and debugging. Maybe I'll get a round tuit one day.

I'm not so familiar with eForth.  Mecrisp is available for a wide range of devices.  I think I mentioned that below.  TMS430 chips and many ARM varieties along with FPGA processors including custom and RISC-V.  Mecrisp is very prolific.

[BitsnBytes]

In one regard, Forth is closely to the bare metal of the CPU than C - namely, the use of the stack. Forth uses reverse polish notation for (just about) everything. i.e., if you want to add two numbers together, you push them both on the stack and then issue the command:

2 5 add .

will give 7 (. prints the number at the top of the stack).

It's interesting because even in assembly language we have to perform arithematic operation on operands when they are in general purpose registers. As far as I know in assembly language we have only PUSH and POP instructions to interact with stack we can't perform operations on Stack.

Regards.

[T3sl4co1l]

Well, depends.  Would you count a stack frame as "operating" on the stack?  That is, allocating a fixed array for random access, while still using the stack (beyond that array) as, well, a stack.

Tim

[gnuarm]

In one regard, Forth is closely to the bare metal of the CPU than C - namely, the use of the stack. Forth uses reverse polish notation for (just about) everything. i.e., if you want to add two numbers together, you push them both on the stack and then issue the command:

2 5 add .

will give 7 (. prints the number at the top of the stack).

It's interesting because even in assembly language we have to perform arithematic operation on operands when they are in general purpose registers. As far as I know in assembly language we have only PUSH and POP instructions to interact with stack we can't perform operations on Stack.

Regards.

Many Forths optimize the stack usage by holding the top of the data stack and sometimes the next on stack in registers.  I'm not certain how they manage this, but they don't push/pop unless it is actually required. 

[iMo]

I've been always a big fan of the Forth Contributed a little bit to FlashForth (pic18/24/33), Amforth (atmega32, 328, 1284), Mecrisp Forth (stm32F1/4, FPGA). Latest demonstration is the MF port to the Lattice iCE40UP5k fpga (with 48bit floating point math as a "because we can" example, btw) in 3 free IDEs.
Programming Forth means creating your "own dictionary" by writing many small "words". The new words are always using the previous words in the dictionary. The dictionary lives on-the-chip, and grows up with the new words added. That is so simple..
All above Forths have got the complete dev system on-the-chip, thus you will need only a serial terminal in order to write your programs (aka "new words"). The performance is similar to a compiled C or a bit better sometimes.. The required ram/flash is usually much smaller than a C build..

For example the MF on a 16bit j1a modded core, running inside the iCE40UP5k fpga (BTW, the entire "dictionary" below occupies 11828 bytes):

Code: [Select]

Mecrisp-Ice 1.2

 ok.
 
words falog f** flog fln (log) fraction integer> >integer lbase epsilon fexp ^fraction
^integer (!) d>u d0< fpow fatan2 facos fasin (fasin) fatan dom2|3 dom3 dom2 (fatan) (taylor2)
2degrees ftan fsincos fcos fsin >range -taylor +taylor (taylor) >taylor rad>deg deg>rad e pi
F# (f#) _f# F.S fd abort" FVARIABLE FCONSTANT >FLOAT -trailing flfrac flexp flint fdigit? flgood
fsign FSQRT d< FE. FS. (E.) R. F. (F.) fsplit F~ F/ F* FMAX FMIN FROUND FLOOR F= F< F- F+ tneg
FROT FNIP FPICK FOVER FSWAP FALIGNED FALIGN FABS F0> F0< F0= F0<> FSIGN? F! F@ FLOATS FLOAT+ S>F
F>D D>F FNEGATE FDROP FDUP FDEPTH FCLEAR SET-PRECISION PRECISION F2/ F2* normalize fshift >exp1
ftemp' expx2 expx1 m1sto m1get fmove 'e2 'e1 'm3 'm2 'm1 longdiv *norm lstemp t+ t2/ t2* sign>exp
exp>sign frshift ud2/ d2/ du< ferror &esign &sign &unsign mxdig bicl ftemp fstak fsp digits -byfp
byfp fpmxst see seec disasm-step memstamp alu. name. disasm-cont disasm-$ insight .s dump new
cornerstone save erase spiwe waitspi m*/ t/ t* 2r@ 2r> 2>r tnegate 2constant 2variable timer1 random
randombit tickshh ticksh ticksl now ms endcase endof of case s" within pad unused ." mod / /mod move
u.r .r d.r rtype u. . d. ud. (d.) #> #s # sign hold <# hld BUF BUF0 pick roll spaces */ */mod fm/mod
sm/rem sgn constant variable m* >body create repeat while else <= >= u<= u>= ( [char] ['] eint? dint
eint load spi> >spi spix idle xor! bic! bis! quit evaluate refill accept number \ char ' postpone
literal abort rdrop r@ r> >r hex binary decimal unloop j i +loop loop ?do leave do recurse does>
until again begin then if ahead ; exit :noname : ] [ immediate foldable sliteral s, compile, c, ,
allot parse parse-name source 2! 2@ cmove> cmove fill sfind align aligned words here tib init forth
>in base state /string type count .x .x2 bl cr space c! c@ emit key key? emit? um/mod * um* d2* d0=
m+ s>d dabs d- dnegate d+ depth io@ io! nip over dup swap u< < = invert not or and xor - + ! 2/ 2*
cells abs bounds umax umin max min 2over 2swap +! 2dup ?dup 2drop tuck -rot rot true false drop u>
0> 0< > 0<> <> cell+ 0= rdepth @ 1- negate 1+ arshift rshift lshift execute  ok.
  ok.
here . 11828  ok.
unused . 3532  ok.
  ok.
pi fs. 3.141593e0  ok.
pi f# 1.23456e-775 f/ fs. 2.544706e775  ok.
The last 2 lines above converted to "Basic":
print pi;
3.141593e0
print pi/1.23456e-775;
2.544706e775

[westfw]

In one regard, Forth is closely to the bare metal of the CPU than C - namely, the use of the stack.

Except that Forth runs fine on chips without any hardware stack instructions, and frequently uses separate stacks for data and instruction paths...


Yeah, I'm somewhat familiar with Forth.  Read the magazine articles and most of the book (back when it was The Book!) Typed in the 8080 version for a simulator, implemented a few subsets, even wrote some raw postscript for a job, sort-of.It always struck me as elegant in its minimal forms - you can write a small and useful interpreter for a very small chip indeed.   You can implement neat little "interactive" systems.  It's closer to "metal" than most interpreters.  And it is interesting for those reasons.

But it also strikes me has rapidly becoming unwieldy, unreadable, and ... unnecessary in a more modern world, like it was purposely ignoring decades worth of "software engineering best practices" WRT things like code readability, editing, data structuring, file systems, libraries, source code management, strong typing, weak typing (I mean, separate operators for 16bit add and 32bit add, but no checking that the arguments match?)
I mean, it's possible that I've just missed all the "modernization" of Forth (good Postscript loos OK), but it certainly seems to be the old-style versions that show up more often...

[gnuarm]

But it also strikes me has rapidly becoming unwieldy, unreadable, and ... unnecessary in a more modern world, like it was purposely ignoring decades worth of "software engineering best practices" WRT things like code readability, editing, data structuring, file systems, libraries, source code management, strong typing, weak typing (I mean, separate operators for 16bit add and 32bit add, but no checking that the arguments match?)
I mean, it's possible that I've just missed all the "modernization" of Forth (good Postscript loos OK), but it certainly seems to be the old-style versions that show up more often...

As a user of Forth and VHDL which are pretty much polar opposites regarding strong typing, I like the lack of strong typing in Forth and like the strong typing in VHDL.

In Forth I don't find the lack of strong typing to be an issue because the code is written and tested in small pieces where you don't really need so much protection.  I only wish I could write and test VHDL interactively like I can with Forth.  However, since it is not interactive I find the strong typing helps to assure the design is solid with much less debugging unforeseen errors.

So the real issue is what are you willing to give up in the way of protection from shooting yourself in the foot compared to being able to dance the night away while developing and debugging code?  Since it would be hard, but not impossible as some Forths have typing, to include data checks for stack data while retaining the ease of use of an interpreted language, I prefer the interactivity.

[westfw]

In Forth ... the code is written and tested in small pieces

Ah.  Another bit that is contrary to modern practices.  :-)

Forth also has "problems" with ROM-heavy systems and Harvard architectures.

Don't get me wrong.  I spent about 6 years of my career programming almost exclusively in Assembly Language, and I liked it.   But ... it's not The Way That Things Are Done, any more.  And with good reason.

even in assembly language we have to perform arithematic operation on operands when they are in general purpose registers.

That depends on the architecture.  Some architectures can have one or both arguments in memory.  (old, not-very-fast architectures, perhaps, but still...)

Code: [Select]

    ;; Forth "+" operator, on a machine with "register, memory" operations.
    pop dataSP, Temp      ; Pop top of data stack.
    addm Temp, (dataSP)   ; add value to the new top of data stack value.


[cgroen]

I used Forth for a short time in the mid to late 80'.
Have not touched it since, and don't plan to, also don't plan on using Basic or Comal again (also don't plan on riding a horse-wagon instead of a car anytime soon).

[gnuarm]

In Forth ... the code is written and tested in small pieces

Ah.  Another bit that is contrary to modern practices.  :-)

Forth also has "problems" with ROM-heavy systems and Harvard architectures.

How is that exactly?   By ROM heavy do you mean RAM challenged?   I can't say I'm familiar with the various techniques, but I'm pretty sure people have found ways.  One method I use is to develop on a version of the chip with more RAM.  It works, then final test on the version to be shipped, and ship!

[SiliconWizard]

But it also strikes me has rapidly becoming unwieldy, unreadable, and ... unnecessary in a more modern world, like it was purposely ignoring decades worth of "software engineering best practices" WRT things like code readability, editing, data structuring, file systems, libraries, source code management, strong typing, weak typing (I mean, separate operators for 16bit add and 32bit add, but no checking that the arguments match?)

Yeah, same thought here.
As much as I appreciate Forth's simplicity and relative elegance, it's IMHO pretty much unmaintainable, can't exhibit any form of data structure or structured code really, no type check, almost no possibiliy of static analysis (if there is, I'd be curious to take a look!), everything in a whole flat "world"... Yeah. As to using "stacks" as the core memory management, it has pros and cons. Would take quite a while to fully detail that.

OTOH, the interpreters/compilers are so simple to write that it's much easier to make them bug-free.

[helius]

IMHO...can't exhibit any form of data structure or structured code really, ... everything in a whole flat "world"

Opinions are fine, but these statements are errors.
You can have multiple dictionaries for different purposes in Forth. The "whole flat world" is in your imagination, not an actual requirement.

[bd139]

Indeed.

Also to point out, no data structures?!?!?! The bloody FORTH dictionary in the compiler is a linked list?!?!?! Also ALLOCATE/FREE implementations are usually heap based, which is another data structure, of course written in FORTH and compiled using the compiler which uses a dictionary that is a linked list.

As for structured code, everything I have done in FORTH is structured. What is : for?

I don't think anyone knows how anything works these days. People need to write more compilers!

[iMo]

Forth allows a lot of trickery and magics only pretty experienced users master..
Standard users (like me, and 99,98% of others) usually write words which blink LEDs or do some math..
Mastering Forth requires a different mindset and dedication, indeed 

[tszaboo]

I have never used Forth why?

The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.

Today's youth. Thinking Python/RPi stuff is efficient embedded stuff.

Actually, an average python programmer could write better and faster programs, than 90% of C programmers, because they can harness the power of the best C programmers.
Take a sorting algorithm for example. Just think about for a second, how do you write the fastest sorting algorithm in C or Forth? You know the answer?
I tell you how you sort a variable called array in python: array.sort()
It doesnt look much, right? In the background it calls a sorting algorithm written by the best computer scientists ... in C.

But take something else for example. Matrix multiplications. It takes literally 4 lines of code, to multiply the matrix on your GPU, which is a thousand times faster, rather than the CPU. Try doing this in Forth. Or Fortran. I hope you remember those memory addresses for PCI-e memory transfers, and you are good at setting up DMAs.

[iMo]

..
Take a sorting algorithm for example. Just think about for a second, how do you write the fastest sorting algorithm in C or Forth? You know the answer?
I tell you how you sort a variable called array in python: array.sort()
It doesnt look much, right? In the background it calls a sorting algorithm written by the best computer scientists ... in C.

But take something else for example. Matrix multiplications. It takes literally 4 lines of code, to multiply the matrix on your GPU, which is a thousand times faster, rather than the CPU. Try doing this in Forth. Or Fortran. I hope you remember those memory addresses for PCI-e memory transfers, and you are good at setting up DMAs.

You can do the same in Forth, provided you have got the right "word" handy.. 
PS: and yes - that is the major issue with Forth I see - sharing or publishing "libraries" is not common in the Forth community..

[helius]

Actually, an average python programmer could write better and faster programs, than 90% of C programmers, because they can harness the power of the best C programmers.
Take a sorting algorithm for example. Just think about for a second, how do you write the fastest sorting algorithm in C or Forth? You know the answer?
I tell you how you sort a variable called array in python: array.sort()
It doesnt look much, right? In the background it calls a sorting algorithm written by the best computer scientists ... in C.

But take something else for example. Matrix multiplications. It takes literally 4 lines of code, to multiply the matrix on your GPU, which is a thousand times faster, rather than the CPU. Try doing this in Forth. Or Fortran. I hope you remember those memory addresses for PCI-e memory transfers, and you are good at setting up DMAs.

Also known as "it makes no difference how shit the language is as long as it has a large library".
At one time this would have made Perl the greatest ever, if you ignore languages and only compare libraries.

[gnuarm]

..
Take a sorting algorithm for example. Just think about for a second, how do you write the fastest sorting algorithm in C or Forth? You know the answer?
I tell you how you sort a variable called array in python: array.sort()
It doesnt look much, right? In the background it calls a sorting algorithm written by the best computer scientists ... in C.

But take something else for example. Matrix multiplications. It takes literally 4 lines of code, to multiply the matrix on your GPU, which is a thousand times faster, rather than the CPU. Try doing this in Forth. Or Fortran. I hope you remember those memory addresses for PCI-e memory transfers, and you are good at setting up DMAs.

You can do the same in Forth, provided you have got the right "word" handy.. 
PS: and yes - that is the major issue with Forth I see - sharing or publishing "libraries" is not common in the Forth community..

Actually there are many Forth libraries available.  The late Julian V. Noble was noted for his scientific Forth library as one example. 
https://www.taygeta.com/fsl/docs/NobleArchive.html

You need to search about a bit and there are lots of resources for Forth. 

[gnuarm]

Forth allows a lot of trickery and magics only pretty experienced users master..
Standard users (like me, and 99,98% of others) usually write words which blink LEDs or do some math..
Mastering Forth requires a different mindset and dedication, indeed 

While your initial statement is true, the apparent implication is not.  What you call "trickery" is actually aspects of the language that other languages simply don't have.  For example, you can define an array to simply use whatever offset you hand it with the repercussion of memory violations from bad offsets.  Or you can define arrays that do bounds checking.  You can define arrays that tell you how much of the array is in use (like character string lengths).  You can define an array that keeps a running total of the elements. 

What's even better is you can define words to use to define these different types of arrays.  So one word to define the new array type.  Then use that word to define the arrays to be used. 

You might call that "trickery".  The tool doesn't get in the way of doing crazy things.  The tool doesn't get in the way of doing fantastic things either. 

In VHDL I wanted to add an operator to my program (yes, I consider VHDL code to be a program).  Seems I can create functions and have them treated the same as any other function in the system with overloading for various types.  But not for operators.  I can define an existing operator for new data types, but "read my lips, no new operators" to paraphrase senior Bush.  That got in the way of what I was trying to do. 

I only wish I could design FPGAs at the hardware level with Forth.