Forth - How many know about and use it?

[westfw]

First of all...  I don't mean to critique Forth as a Language.  The question here is "why isn't Forth more popular, especially among the HW crowd?")

no data structures?!?!?! The bloody FORTH dictionary in the compiler is a linked list?!?!?! Also ALLOCATE/FREE implementations are usually heap based

You're conflating internal use of data structures with making them easily available to people USING the language.
I can write an assembler in Java, but that doesn't make the assembler "object oriented."   And then I can write object-oriented code in the assembly language, but it wasn't HELPFUL to me doing so.

Try implementing one of the "Programming 101" examples of structs/records/whatever using forth.  Here's one:   https://www.pascal-programming.info/lesson11.php

Or...  Here's a blinky demo from mecrisp for MPS430:

Code: [Select]

\ Pins wirings internal:

\   P1.0 Green LED
\   P1.1 Button S2
\   P2.0 TXD
\   P2.1 RXD
\   P4.5 Button S1
\   P4.6 Red LED

$200 constant P1IN
$202 constant P1OUT
$204 constant P1DIR

: blinky ( -- )
  1 P1DIR c!
  begin
    1 P1OUT cxor!
    60000 0 do loop
  key? until
;How would that be re-written to make IN, OUT, and DIR "fields" of P1 so that they'd apply to P2, P3, etc, in a way that would be "pretty" to modern programmers.  Something better, with more error checking "somewhere" than

Code: [Select]

1 P1 OUT + cxor!(I mean, that's essentiall machine language.  If I write "p1->out ^= 1;" in C, something has checked that p1 is a pointer, and that out is something that p1 can point to...)

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

Word definitions (subroutines) are typically one or a very few lines and so can be written and debugged interactively at the terminal interface.

So, after I've loaded up my interactive Forth core, fiddled around and created new words that do what I want, how do I "save" my efforts in source form, preferably with any comments I might have entered while I was fiddling?  Isn't it mostly like those old BASICs where your text would be instantly tokenized, and "LIST" would type back a horribly abbreviated form?

you will need only a serial terminal in order to write your programs

Typically languages like C or python use the PC as the compiler and must use some form of debugger to interact with the target.  I find these tools to be more awkward than the terminal interface.

Failing to notice that your "terminal" has enough computational power to do nice formatting, error checking, and optimization (ie edit and compile) of your program would be one of those "modern SW Engineering paradigms" that I was thinking about that is missing from Forth.  Sheesh, even DEC TECO got a "pre-processor" that let you use printable characters and non-significant whitespace.

sharing or publishing "libraries" is not common in the Forth community

Ditto.  And deadly.   "Forth code is hard to share."

Also known as "it makes no difference how shit the language is as long as it has a large library".

True for a large range of uses of computer languages.  At my University, they taught APL to the business majors.  Sort of.   What they really had was a bunch of pre-made fancy functions that users could combine with some elementary data manipulation to analyze stuff like economic or business data.  Having APL around let you combine the elements of the language, even if they were really simple, with the Powerfull pre-written functions.  Forth allows that as well (ie the "core" makes an excellent user interface for a bunch of application-specific "words.")  A lot of interpreters do that - LISP and Python, for example.  (and I curse some user interfaces all the time for not allowing stuff like "move (3.2 .4 +, 12) instead of making me do the addition myself.)

You can put hooks on defered words, redefining what they do at runtime.

Somewhat close to EVIL, imo.  C++ programmers do it too.  There was well-deserved condemnation of the guy who had overloaded "+" in "a = b + c" to change the value of b.  Shudder.  They didn't like my self-modifying assembler, either.   And it interferes with portability and sharing, perhaps.

I was specifically referring to running on a small embedded target.

Forth still needs its core.  I've written C for chips with 1k of program memory or less.  I don't think the basics of most Forth systems would fit.  Certainly not if you want to include the actual dictionary and parser.

Hmm.  I specifically think that Forth MISSED the "microcontroller age."  It was all the rage on your 1802 or 8080 with 8k of RAM and some ROM.  At least equal, but much faster, than the 4k or 8k BASICs of the same era (and with other advantages.)  But chips like the 8052 with 8k of ROM and 256bytes of RAM, or a PIC with 2k of Flash and 72 bytes of RAM.  Suddenly "create new words interactively" didn't work at all, and Forth was essentially reduced to being a fancy and obscure caclulator.

That was the same age that latched on to cross-compilation in a big way, and that didn't work so well for Forth, either.  And PCs with actual mass storage and file systems, which Forth didn't do very well ("Screens" read, based on track and sector number?  Hmmph.)

[JagV12]

Forth - How many know about and use it? Well, I use my HP48 every day and love it    Does that count ?

[gnuarm]

First of all...  I don't mean to critique Forth as a Language.  The question here is "why isn't Forth more popular, especially among the HW crowd?")

no data structures?!?!?! The bloody FORTH dictionary in the compiler is a linked list?!?!?! Also ALLOCATE/FREE implementations are usually heap based

You're conflating internal use of data structures with making them easily available to people USING the language.
I can write an assembler in Java, but that doesn't make the assembler "object oriented."   And then I can write object-oriented code in the assembly language, but it wasn't HELPFUL to me doing so.

Try implementing one of the "Programming 101" examples of structs/records/whatever using forth.  Here's one:   https://www.pascal-programming.info/lesson11.php

Or...  Here's a blinky demo from mecrisp for MPS430:

Code: [Select]

\ Pins wirings internal:

\   P1.0 Green LED
\   P1.1 Button S2
\   P2.0 TXD
\   P2.1 RXD
\   P4.5 Button S1
\   P4.6 Red LED

$200 constant P1IN
$202 constant P1OUT
$204 constant P1DIR

: blinky ( -- )
  1 P1DIR c!
  begin
    1 P1OUT cxor!
    60000 0 do loop
  key? until
;How would that be re-written to make IN, OUT, and DIR "fields" of P1 so that they'd apply to P2, P3, etc, in a way that would be "pretty" to modern programmers.  Something better, with more error checking "somewhere" than

Code: [Select]

1 P1 OUT + cxor!(I mean, that's essentiall machine language.  If I write "p1->out ^= 1;" in C, something has checked that p1 is a pointer, and that out is something that p1 can point to...)

You seem to be talking about records as I'm familiar with them.  Yes, Forth supports them.  I'm not familiar with them as I have never needed them in Forth.  I've very seldom used them in any language.  I might have used a record once in VHDL as a way of referring to a word as two bytes, but it was a bit awkward.

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

Word definitions (subroutines) are typically one or a very few lines and so can be written and debugged interactively at the terminal interface.

So, after I've loaded up my interactive Forth core, fiddled around and created new words that do what I want, how do I "save" my efforts in source form, preferably with any comments I might have entered while I was fiddling?  Isn't it mostly like those old BASICs where your text would be instantly tokenized, and "LIST" would type back a horribly abbreviated form?

When interactively "fiddling" it is not common to write comments.  As is common in Forth, there is no one way to do things, but typically a PC is used as the terminal, code is written to a source file and downloaded to the target as source which is compiled as it is downloaded.  Then the word(s) defined is/are debugged interactively.  That's how I do it.  If your target has mass storage then everything is saved on the target and it either has it's own console or the PC is used as a terminal without downloading files.  I have seen targets include editors, but I don't think that is common anymore.  They were typically less powerful editors and with PCs being everywhere they serve as useful tools.

you will need only a serial terminal in order to write your programs

Typically languages like C or python use the PC as the compiler and must use some form of debugger to interact with the target.  I find these tools to be more awkward than the terminal interface.

Failing to notice that your "terminal" has enough computational power to do nice formatting, error checking, and optimization (ie edit and compile) of your program would be one of those "modern SW Engineering paradigms" that I was thinking about that is missing from Forth.  Sheesh, even DEC TECO got a "pre-processor" that let you use printable characters and non-significant whitespace.

What is "edit and compile"?  I feel like The Dowager Countess of Grantham, "What is a weekend?" 

Compiling Forth programs is so simple it typically is invisible.  A source file is compiled as fast as it can be transferred over the fastest serial port and often as fast as it is read from disk. 

Forth programs don't contain syntactical baggage and so don't require pretty print to organize the visual aspects of programs.  That's left to the writer and there are many styles.  Error checking is somewhat minimal as there is no type checking and the user is free to make all the disastrous errors they want.  Rather than throw in a lot of complication to try to compensate for the programmer, the emphasis is on finding mistakes quickly and easily, hence the small word concept.  I recall a bit of an epiphany when Jeff Fox told me that many beginner errors have to do with stack mismatches (not taking the right number of parameters from the stack or not leaving the right number on the stack) which means the programmer can't count.  That sounds trite, but in a word that is written with just 5, 8 or even 10 words in it, how hard is it to count the stack data???  That's when I really saw that Forth is not like using other languages.  Most of what you need to know is much, much simpler. 

Then Forth makes up for it with some really odd things you do need to learn.

sharing or publishing "libraries" is not common in the Forth community

Ditto.  And deadly.   "Forth code is hard to share."

Did you look at Julian Noble's work?  It is an example of how work should be shared.  There are crap libraries in every language.  That's great reason not to use any libraries, or at least use them with extreme care.  Same with footprints in PCB layout.  I draw my own so I am debugging my mistakes, not someone else's.

Also known as "it makes no difference how shit the language is as long as it has a large library".

True for a large range of uses of computer languages.  At my University, they taught APL to the business majors.  Sort of.   What they really had was a bunch of pre-made fancy functions that users could combine with some elementary data manipulation to analyze stuff like economic or business data.  Having APL around let you combine the elements of the language, even if they were really simple, with the Powerfull pre-written functions.  Forth allows that as well (ie the "core" makes an excellent user interface for a bunch of application-specific "words.")  A lot of interpreters do that - LISP and Python, for example.  (and I curse some user interfaces all the time for not allowing stuff like "move (3.2 .4 +, 12) instead of making me do the addition myself.)

Sounds like you found something you like about Forth.

You can put hooks on defered words, redefining what they do at runtime.

Somewhat close to EVIL, imo.  C++ programmers do it too.  There was well-deserved condemnation of the guy who had overloaded "+" in "a = b + c" to change the value of b.  Shudder.  They didn't like my self-modifying assembler, either.   And it interferes with portability and sharing, perhaps.

That's the sort of logic that would ban autos because someone used one to run through a crowd of people.

I was specifically referring to running on a small embedded target.

Forth still needs its core.  I've written C for chips with 1k of program memory or less.  I don't think the basics of most Forth systems would fit.  Certainly not if you want to include the actual dictionary and parser.

Sorry, you are saying you've written a C tool chain to run on an MCU with 1K of RAM? 

You can use Forth on a PC to target an MCU that is too small to host the compiler.  It's called cross-compiling. 

Hmm.  I specifically think that Forth MISSED the "microcontroller age."  It was all the rage on your 1802 or 8080 with 8k of RAM and some ROM.  At least equal, but much faster, than the 4k or 8k BASICs of the same era (and with other advantages.)  But chips like the 8052 with 8k of ROM and 256bytes of RAM, or a PIC with 2k of Flash and 72 bytes of RAM.  Suddenly "create new words interactively" didn't work at all, and Forth was essentially reduced to being a fancy and obscure caclulator.

I can count on one hand, no one finger, the number of times I dealt with devices with such limitations.  That simply requires the use of a cross compiler and a tethered target.  I guess you didn't have the right Forth tools.

That was the same age that latched on to cross-compilation in a big way, and that didn't work so well for Forth, either.  And PCs with actual mass storage and file systems, which Forth didn't do very well ("Screens" read, based on track and sector number?  Hmmph.)

Really?  I design boards for a living and one I have in production uses an FPGA with an FPGA on the test fixture.  The test fixture attaches to a PC via a serial port and Win32Forth on the PC runs the test program that exercises the target, collects the data and puts the results to be saved in the Windows paste buffer for the operator to paste into the spread sheet.  This is all very expedient.  So much so that the contract assembly house does not charge me for it as it gives them rapid feedback on the quality of their production line.  They consider it part of their quality process. 

I certainly could have done that in C or Python or other languages.  I found Forth's interactivity useful in debugging and validating the code.  So I don't know why you think Forth is not good on a PC.  The Forth standard is slow to remove old things.  If even a small number of users still use a feature, they don't remove it from the standard.  It was relatively recently they removed the flexibility of using other than 2s complement arithmetic.  So blocks are still in the standard as optional.  I don't see them in Win32Forth so you'll have to write your own.  I expect you can find bare metal Forths to work with if you really want blocks.  That's why blocks existed, you know?  They accessed a disk without a file system.  It worked... 

[iMo]

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.

Well, number crunching is something you will not do today with Forth.. Forth is still pretty usable with small MCUs or FPGAs, imho.
But, in comparison to various ..duino communities, for example, the availability of resources for interfacing the zillions of various chips (and other ebay/ali stuff) is almost nil, thus you have to code everything from scratch..
While working with fpgas, for example, you have got a smallish forth_mcu with a basic forth dictionary ("a nucleus") all written in verilog (or vhdl) as a single verilog module. You then mess mainly with your "actual hw design" and you do not touch the "forth_mcu" part (except the i/o into the fabric) anymore. After uploading the fpga bitstream into the fpga you simply connect your terminal via serial to the forth_mcu and upload your dictionary of choice (as the text off your notepad) into the forth_mcu and then talk and work interactively with the fpga's fabric.. An example is here, for example..

[dolbeau]

Isn't Forth the built in language in the ROM of Sun workstations? If so then I know about it and have used it, but I can't claim to "know" it.

I believe that is open boot which is based on the Forth concept. 

Yes, OpenBoot (with evolving variants over the years in Sun PROMs / console) is using Forth - that's the base language used to identify/initialize/use devices from the PROM. OpenBoot evolved in OpenFirmware a.k.a. IEEE 1275-1994, which you can find in e.g. Apple PowerMacs (so theoretically you can use a Sun device in a PMac and vice-versa, in practice it can get a bit weird ) There's an OSS implementation as well, OpenBIOS.

And if you develop HW meant to interact with an OpenBoot/OpenFirmware system, you still need to write Forth to support the HW (e.g. https://github.com/rdolbeau/SBusFPGA/blob/main/sbus-to-ztex/prom.forth to expose devices to the PROM in OpenBoot 2.x Sun systems...)

[gnuarm]

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.

Well, number crunching is something you will not do today with Forth.. Forth is still pretty usable with small MCUs or FPGAs, imho.

I have no idea why you say that.  Forth was invented to control telescopes which is very much about number crunching, but in terms of real time work (they have to be continually moving) as well as the high precision math required to keep the telescope at just the right spot. 

It has also been used to manage space vehicles which requires significant number crunching.  A good example was the Philae lander, but I can't find any details on it now other than that it used two RTX2010 radiation hardened stack processors programmed in Forth. 

Whatever...  much like the funny (and wrong) ideas many people have about FPGAs, people have funny (and wrong) ideas about Forth. 

[tszaboo]

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.

Yes, and the BMW M3 is only faster than a Pontiac Aztec for a reason know as "They put a better engine in it"

[iMo]

Whatever...  much like the funny (and wrong) ideas many people have about FPGAs, people have funny (and wrong) ideas about Forth.

.. and those could be the final words in this thread 

[westfw]

Anyone here using it, why or why not?

Well, I told you why not.
"I don't use the things you seem to think are important" and "the bad examples you've seen could be better" are fine for you, but not really adequate reasons for me to change my mind.

I still have things I like about TECO, too.  But not enough to go back to using it, or to suggest that other people use it.

[gnuarm]

Anyone here using it, why or why not?

Well, I told you why not.
"I don't use the things you seem to think are important" and "the bad examples you've seen could be better" are fine for you, but not really adequate reasons for me to change my mind.

I still have things I like about TECO, too.  But not enough to go back to using it, or to suggest that other people use it.

Please don't think my posts are to change your mind exclusively.  My main point in replying is to present an alternative view so others see all sides of an issue.

[brucehoult]

Anyone here using it, why or why not?

Well, I told you why not.
"I don't use the things you seem to think are important" and "the bad examples you've seen could be better" are fine for you, but not really adequate reasons for me to change my mind.

I still have things I like about TECO, too.  But not enough to go back to using it, or to suggest that other people use it.

TECO? Sheer luxury! I used Data General "SPEED", which was a bad and more limited clone of TECO.

There doesn't seem to be a manual online so you'll have to take my word for it.

[brucehoult]

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.

I'm confused. You appear to be a user and advocate of FORTH, but you don't understand the basics of how it is implemented?

Keeping TOS in a register vs a pure memory stack (in C):

Word TOS in a register Pure stack in memory Advantage + TOS = TOS + 0[SP];SP++ 1[SP] = 1[SP] + 0[SP];SP++ reg drop TOS = 0[SP];SP++ SP++ mem dup --SP; 0[SP] = TOS --SP; 0[SP] = 1[SP] reg swap T = TOS; TOS = 0[SP]; 0[SP] = T T1 = 0[SP]; T2 = 1[SP]; 0[SP] = T2; 1[SP] = T1 reg over --SP; 0[SP] = 1[SP]; 1[SP] = TOS --SP; T = 2[SP]; 0[SP] = 2[SP] = 1[SP]; 1[SP] = T reg nip SP++ 1[SP] = 0[SP]; SP++ reg tuck --SP; 0[SP] = TOS; TOS = 1[SP] --SP; 0[SP] = 2[SP] equal rot T = 0[SP]; 0[SP] = 1[SP]; 1[SP] = TOS; TOS = T T = 0[SP]; 0[SP] = 1[SP]; 1[SP] = 2[SP]; 2[SP] = T reg The only operation that favours not keeping TOS in a register is DROP. The only thing that is equal is TUCK. Keeping the top two stack elements in registers improves a few operations but makes others worse. It can be worth it because it allows things such as + to load the new 2nd stack item after starting the add, rather than waiting for it. But once you get to that point it's probably better to have the compiler use registers for an entire definition and only update the stack in memory at the end of the definition.

[gnuarm]

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.

I'm confused. You appear to be a user and advocate of FORTH, but you don't understand the basics of how it is implemented?

Keeping TOS in a register vs a pure memory stack (in C):

Word TOS in a register Pure stack in memory Advantage + TOS = TOS + 0[SP];SP++ 1[SP] = 1[SP] + 0[SP];SP++ reg drop TOS = 1[SP];SP++ SP++ mem dup --SP; 0[SP] = TOS --SP; 0[SP] = 1[SP] reg swap T = TOS; TOS = 0[SP]; 0[SP] = T T1 = 0[SP]; T2 = 1[SP]; 0[SP] = T2; 1[SP] = T1 reg over --SP; 0[SP] = 1[SP]; 1[SP] = TOS --SP; T = 2[SP]; 0[SP] = 2[SP] = 1[SP]; 1[SP] = T reg nip SP++ 1[SP] = 0[SP]; SP++ reg tuck --SP; 0[SP] = TOS; TOS = 1[SP] --SP; 0[SP] = 2[SP] equal rot T = 0[SP]; 0[SP] = 1[SP]; 1[SP] = TOS; TOS = T T = 0[SP]; 0[SP] = 1[SP]; 1[SP] = 2[SP]; 2[SP] = T reg The only operation that favours not keeping TOS in a register is DROP. The only thing that is equal is TUCK. Keeping the top two stack elements in registers improves a few operations but makes others worse. It can be worth it because it allows things such as + to load the new 2nd stack item after starting the add, rather than waiting for it. But once you get to that point it's probably better to have the compiler use registers for an entire definition and only update the stack in memory at the end of the definition.

You are confused by my statement, "I'm not certain how they manage this".  I was referring specifically to minimizing stack operations when the top two elements are in registers.  This requires keeping track of the number of elements in registers rather than always keeping two.  I've read of this being done gaining improvements as a result.  I suppose it is done at compile time rather than run time and so is limited to optimizing within a word definition.  Or perhaps a given word optimizes itself and the definition indicates the final state of the stack to be accommodated by the compiler.   This is then used by any definition that uses this word.  Interactive use would require a "patch up" to assure the stack is in a known state at any given time.

When you talk about the compiler optimizing word definitions, that is another subject entirely where many optimizations are possible just like in any compiler.  In those cases Forth can achieve similar speeds as any other language. 

I'm not a compiler guy.  I use compilers, not write them.

[brucehoult]

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.

I'm confused. You appear to be a user and advocate of FORTH, but you don't understand the basics of how it is implemented?

Keeping TOS in a register vs a pure memory stack (in C):

Word TOS in a register Pure stack in memory Advantage + TOS = TOS + 0[SP];SP++ 1[SP] = 1[SP] + 0[SP];SP++ reg drop TOS = 1[SP];SP++ SP++ mem dup --SP; 0[SP] = TOS --SP; 0[SP] = 1[SP] reg swap T = TOS; TOS = 0[SP]; 0[SP] = T T1 = 0[SP]; T2 = 1[SP]; 0[SP] = T2; 1[SP] = T1 reg over --SP; 0[SP] = 1[SP]; 1[SP] = TOS --SP; T = 2[SP]; 0[SP] = 2[SP] = 1[SP]; 1[SP] = T reg nip SP++ 1[SP] = 0[SP]; SP++ reg tuck --SP; 0[SP] = TOS; TOS = 1[SP] --SP; 0[SP] = 2[SP] equal rot T = 0[SP]; 0[SP] = 1[SP]; 1[SP] = TOS; TOS = T T = 0[SP]; 0[SP] = 1[SP]; 1[SP] = 2[SP]; 2[SP] = T reg The only operation that favours not keeping TOS in a register is DROP. The only thing that is equal is TUCK. Keeping the top two stack elements in registers improves a few operations but makes others worse. It can be worth it because it allows things such as + to load the new 2nd stack item after starting the add, rather than waiting for it. But once you get to that point it's probably better to have the compiler use registers for an entire definition and only update the stack in memory at the end of the definition.

You are confused by my statement, "I'm not certain how they manage this".  I was referring specifically to minimizing stack operations when the top two elements are in registers.  This requires keeping track of the number of elements in registers rather than always keeping two.

No.

Keeping the top two elements in registers means ALWAYS keeping the top two elements in registers. It's a simple extension of what I showed above. e.g. "+" becomes "TOS += SOS; SOS = 0[SP]; SP++". It's often no fewer operations, but they're just in a possibly higher performing order, especially on a superscalar CPU.

If you are keeping track of how many elements are in registers then you are implementing the general solution described in my last sentence -- and if you limit it to only two registers then you are missing out on a lot.

[gnuarm]

You are confused by my statement, "I'm not certain how they manage this".  I was referring specifically to minimizing stack operations when the top two elements are in registers.  This requires keeping track of the number of elements in registers rather than always keeping two.

No.

Keeping the top two elements in registers means ALWAYS keeping the top two elements in registers. It's a simple extension of what I showed above.

If you are keeping track of how many elements are in registers then you are implementing the general solution described in my last sentence -- and if you limit it to only two registers then you are missing out on a lot.

You just contradicted yourself.  You say you have to always have two operands in register, then you say it can be optimized to knowing how many are in registers. 

Sure, you can extend the concept to other optimizations, but there is always a point at which you cry uncle and stop with the compiler writing and get back to work on the application.   Unless the compiler is your application.  Then I guess you just live in the rabbit hole and don't worry about it.  Rabbits can be very accommodating.  : )

[techman-001]

I've been a user of Forth for a long time, but I've never become an expert.  The only active Forth community I know of is the newsgroup, comp.lang.forth which is fairly active. 

I'm just curious how popular this language this among the hardware oriented crowd.  The language is close to the metal so to speak and its interactive nature makes it ideal for working on or with hardware. 

I know python is popular with the rPi crowd.  Not sure what is mostly used on the Arduino.  I do know Forth is available for those platforms and many others.  In fact, it is hard to find a processor Forth hasn't been ported to. 

Anyone here using it, why or why not?

Hi Rick,

I'm still using Mecrisp-Stellaris Forth, and have been since 2014.

I use it because Forth, due to its unique nature is a hotbed of innovation. Sure the original Forths from the 70's are long out of date now except on old processors of that era, but nowadays Forth runs on todays MCU's with modern development support.

Anyone who thinks we still use that ancient Forth stuff probably thinks we drive a Stanley Steamer, instead of a Tesla.

For instance my Forth terminal uses the ARM SWD facility (with a PC client terminal) for comms and uploading source. It's so fast that the Forth Core has to halt on errors (because it's too fast to see) but it also highlights errors in red text.

It has no dependency on the USART, or the System Clock. I can change the System Clock from 48Mhz to 8 Mhz and I don't lose terminal comms.

We also have a program that transforms any CMSIS-SVD to memory mapped Words, and bitfield Words in an intelligent manner, for instance if a bitfield is a single bit and read-only, the generated Word appends a "?" and creates a bit-test Word as below.

Code: [Select]

: RCC_CR_HSIRDY? ( -- 1|0 ) 1 bit RCC_CR bit@ ; \ RCC_CR_HSIRDY, Internal High Speed clock ready  flag
A STM32F746 has 14,338 bitfields and they are all auto transformed into Forth Words, which would be impossible to do manually. The C programming Language also uses CMSIS-SVD to create its header files, as does RUST etc.

The transformed Words are easily inserted into my source using a vim editor key, no copy and paste is required. Because the transforms include the 'description' field, this often means that I don't need to consult the Technical Manual, some of which are over 3000 pages.

We also have Register Print Words for easy development and bug fixes. Here you can see that the HSI clock is on and ready, the HSE clock is on and ready and the PLL (phase locked loop) is also on and ready. This is of course in interactive *real time* as only Forth can do.

Code: [Select]

RCC_CR.   $03035183
            P             H H                                   
            L P         C S S H                             H   
            L L         S E E S                             S H
            R L         S B R E                             I S
            D O         O Y D O|    HSICAL     |         |  R I
            Y N         N P Y N|7:6:5:4:3:2:1:0| HSITRIM |  D O
           |2|2|       |1|1|1|1|1|1|1|1|1|1| | |4:3:2:1:0|  Y N
~|~|~|~|~|~|5|4|~|~|~|~|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|~|1|0
0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 1 0 1 0 0 0 1 1 0 0 0 0 0 1 1
I just took that screepic, right now, on a running STM32F0 Discovery board.

My project management system includes the Fossil SCM, and uses the Sphinx document system complete with indexes and cross refs to auto generate  a README.HTML project file.

I used Mecrisp-Stellaris to create a bootable binary for diagnosing the infamous Blue Pill board, to determine what MCU is actually in use. Is it a genuine STM32F103C8 or a Chinese 'clone' ?

It also tests if the MCU has a 'hidden' extra 64KB of flash by writing and reading every Byte.

This binary has been downloaded over 1000 times now, mainly by Windows users in the USA who can easily use the boards USB to obtain the menu via any serial terminal.

Mecrisp-Stellaris runs on most Cortex-M's out there, Mecrisp-Ice runs on Lattice FPGA's, Mecrisp-Quintus runs on RISC-V and MIPS, Mecrisp-Across uses a Cortex-M4 to cross compile for a MSP430 using a JTAG tether. It produces a 80 byte bootable Blinky binary in exactly the same way that C does, i.e. multiple compiler passes and easily fits on a MCU with only 500 bytes of Flash/Fram or whatever.

In the last week, Mecrisp has been ported to the RP2040 and currently is running in Ram only. Running from Flash is still under development. It uses the RP2040 USART and all the source is written in assembly. I imagine it won't be long before a SWDCOM terminal(s) are available for each CPU.

Everyone who actually uses Forth here on this forum will understand what I've just written and I apologize in advance to the C and Python users who probably gave up by line 16 as it's all too weird. 

Rust users probably thought, 'that's interesting, I'll have to look into the parts I don't grok'.

LISP users probably said. 'cool! but what's a MCU' ;-)

[helius]

You can put hooks on defered words, redefining what they do at runtime.

Somewhat close to EVIL, imo.  C++ programmers do it too.  There was well-deserved condemnation of the guy who had overloaded "+" in "a = b + c" to change the value of b.  Shudder.  They didn't like my self-modifying assembler, either.   And it interferes with portability and sharing, perhaps.

Hooks are an important concept in any software system that needs to be adaptable to different situations. Perhaps the program with the most hooks provided and used is Emacs, which is the most flexible document editor. They are also part of every GUI toolkit and web framework.

http://people.cs.aau.dk/~normark/hooks/hypertext/hooks.html

In C++ the analogous concept would be the Bridge or Chain of Responsibility patterns, not overloaded operators—which are not dynamic at all.
The Forth concept with deferred words is much lighter in weight and so is used widely in Forth programs.

A sure sign that a correspondent doesn't understand dynamic languages is the confusion with "self-modifying code". Just because the system is able to change at runtime does not make any part of it "self-modifying". At runtime, functions (Forth words) are redefined by other functions, not by themselves. It is about as "self-modifying" as calling dlopen().

True for a large range of uses of computer languages.  At my University, they taught APL to the business majors.  Sort of.   What they really had was a bunch of pre-made fancy functions that users could combine with some elementary data manipulation to analyze stuff like economic or business data.  Having APL around let you combine the elements of the language, even if they were really simple, with the Powerfull pre-written functions.

An interesting anecdote. Are we to trust our lives, livelihoods, data, money, etc., to "Sort-of programming" of this kind? I think this library dabbling is fine for kids (or business majors), but it has gotten completely out of control in the industry today.

[brucehoult]

You are confused by my statement, "I'm not certain how they manage this".  I was referring specifically to minimizing stack operations when the top two elements are in registers.  This requires keeping track of the number of elements in registers rather than always keeping two.

No.

Keeping the top two elements in registers means ALWAYS keeping the top two elements in registers. It's a simple extension of what I showed above.

If you are keeping track of how many elements are in registers then you are implementing the general solution described in my last sentence -- and if you limit it to only two registers then you are missing out on a lot.

You just contradicted yourself.  You say you have to always have two operands in register, then you say it can be optimized to knowing how many are in registers. 

No. These are two DIFFERENT things:

1) always keeping exactly the top two stack elements in registers

2) keeping a variable number of elements in registers and keeping track from word to word of how many there are. In this case there is no reason (and it's not any easier) to limit it to two rather than using all the 8, 16, or 32 registers you have.

[helius]

1) always keeping exactly the top two stack elements in registers

Is the stack guaranteed to contain at least two elements?

If not, you have a rather more complicated underflow detection and recovery problem, viz. the purely stack in memory implementation.

[brucehoult]

1) always keeping exactly the top two stack elements in registers

Is the stack guaranteed to contain at least two elements?

If not, you have a rather more complicated underflow detection and recovery problem, viz. the purely stack in memory implementation.

FORTH doesn't even check that a floating point add is being performed on FP values, it certainly doesn't in any way check for stack underflow or overflow.

If you do want to detect underflow, you simply define the initial values in the TOS and SOS registers to be undefined -- put 0xDEADBEEF in them if you want. Just compare SP to its initial value, exactly the same as if the stack was entirely in memory.

[gnuarm]

Hooks are an important concept in any software system that needs to be adaptable to different situations. Perhaps the program with the most hooks provided and used is Emacs, which is the most flexible document editor.

https://xkcd.com/378/

[gnuarm]

You are confused by my statement, "I'm not certain how they manage this".  I was referring specifically to minimizing stack operations when the top two elements are in registers.  This requires keeping track of the number of elements in registers rather than always keeping two.

No.

Keeping the top two elements in registers means ALWAYS keeping the top two elements in registers. It's a simple extension of what I showed above.

If you are keeping track of how many elements are in registers then you are implementing the general solution described in my last sentence -- and if you limit it to only two registers then you are missing out on a lot.

You just contradicted yourself.  You say you have to always have two operands in register, then you say it can be optimized to knowing how many are in registers. 

No. These are two DIFFERENT things:

1) always keeping exactly the top two stack elements in registers

2) keeping a variable number of elements in registers and keeping track from word to word of how many there are. In this case there is no reason (and it's not any easier) to limit it to two rather than using all the 8, 16, or 32 registers you have.

Yes, they are different.  I'm glad you understand that.  Your final conclusion does not follow from the previous statements.  The compiler writer decides what he wants to support and where he/she draws the line.

[brucehoult]

You are confused by my statement, "I'm not certain how they manage this".  I was referring specifically to minimizing stack operations when the top two elements are in registers.  This requires keeping track of the number of elements in registers rather than always keeping two.

No.

Keeping the top two elements in registers means ALWAYS keeping the top two elements in registers. It's a simple extension of what I showed above.

If you are keeping track of how many elements are in registers then you are implementing the general solution described in my last sentence -- and if you limit it to only two registers then you are missing out on a lot.

You just contradicted yourself.  You say you have to always have two operands in register, then you say it can be optimized to knowing how many are in registers. 

No. These are two DIFFERENT things:

1) always keeping exactly the top two stack elements in registers

2) keeping a variable number of elements in registers and keeping track from word to word of how many there are. In this case there is no reason (and it's not any easier) to limit it to two rather than using all the 8, 16, or 32 registers you have.

Yes, they are different.  I'm glad you understand that.  Your final conclusion does not follow from the previous statements.  The compiler writer decides what he wants to support and where he/she draws the line.

As you said, you're not a compiler guy. I am. My statements about various ways code for a threaded stack language can be compiled to machine code and its use of registers have been consistent, even if you didn't understand them to be so.

I'm glad you've finally come to agreement with what I was saying for half a dozen messages.

[helius]

FORTH doesn't even check that a floating point add is being performed on FP values, it certainly doesn't in any way check for stack underflow or overflow.

One of these things is not like the other. In the first case, this is just a funny way to say that the data do not carry type information (all different data types cover the same domain). When you call FADD, the operation is performed on FP values whether they are the intended data or not. This mirrors assembler. The second case is a consistency check that Forth certainly can perform (the depth word exists). Whether you require that check or not is subject to various practical considerations.

If you do want to detect underflow, you simply define the initial values in the TOS and SOS registers to be undefined -- put 0xDEADBEEF in them if you want. Just compare SP to its initial value, exactly the same as if the stack was entirely in memory.

I can see now that the SP is incremented/decremented by the same amount regardless of the memory or registers implementations.
So you can check the height by comparing SP. However, the "initial value" is not the same with the two implementations. In a stack in memory, the initial word pointed to by the SP is the bottom of the stack (modulo upwards/downwards growth and pre/post modifying instructions). When the top elements are in registers, the initial word pointed to by SP is not an element at all and never will be. So this is not exactly the same.

[brucehoult]

FORTH doesn't even check that a floating point add is being performed on FP values, it certainly doesn't in any way check for stack underflow or overflow.

One of these things is not like the other. In the first case, this is just a funny way to say that the data do not carry type information (all different data types cover the same domain). When you call FADD, the operation is performed on FP values whether they are the intended data or not. This mirrors assembler. The second case is a consistency check that Forth certainly can perform (the depth word exists). Whether you require that check or not is subject to various practical considerations.

Exactly right.

If you do want to detect underflow, you simply define the initial values in the TOS and SOS registers to be undefined -- put 0xDEADBEEF in them if you want. Just compare SP to its initial value, exactly the same as if the stack was entirely in memory.

I can see now that the SP is incremented/decremented by the same amount regardless of the memory or registers implementations.
So you can check the height by comparing SP. However, the "initial value" is not the same with the two implementations. In a stack in memory, the initial word pointed to by the SP is the bottom of the stack (modulo upwards/downwards growth and pre/post modifying instructions). When the top elements are in registers, the initial word pointed to by SP is not an element at all and never will be. So this is not exactly the same.

Indeed so.