Forth - How many know about and use it?  - Page 1
Forum section: electronics / general

author: gnuarm
author_rank: Super Contributor
timestamp: February 05, 2021, 05:02:45 pm
content: 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?

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: February 05, 2021, 06:34:36 pm
content: I used to play around with Forth years ago on my Sinclair ZX Spectrum. I even remember typing in a Z80 assembler listing of FIG Forth.I hadn't realized it was still going strong and would certainly take a look. After all, the RP really should use a language that uses RP.

author: gnuarm
author_rank: Super Contributor
timestamp: February 05, 2021, 07:09:22 pm
content: There are many, many Forths out there. The one I prefer at the moment is Mecrisp by Matthias Koch. It is implemented on the TMS430 family as well as many ARMs (a long list of boards supported) and even other devices like the rPi and even an FPGA custom stack processor.http://mecrisp.sourceforge.net/

author: exe
author_rank: Unknown
timestamp: February 05, 2021, 08:24:11 pm
content: At some moment in time I was attracted by its power and simplicity and wanted to use for a microcontroller (I think it was atmega or something), it was in early-mid 2000x. But reverse polish notation doesn't land in my brain. Contrary, forward polish notation is how I think about expressions. I guess that's why I didn't use it.

author: james_s
author_rank: Super Contributor
timestamp: February 05, 2021, 09:39:08 pm
content: 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.

author: grumpydoc
author_rank: Super Contributor
timestamp: February 05, 2021, 10:09:40 pm
content: Quote from: james_s on February 05, 2021, 09:39:08 pmYes, it is (never used it though).Postscript is also "related" to Forth, in that it is also a stack-oriented language.

author: Syntax Error
author_rank: Frequent Contributor
timestamp: February 05, 2021, 10:59:41 pm
content: Forth, this is the first mention I've heard in decades! Back in the day, our school had a Jupiter Ace computer. But it used Forth, so no-one knew how to program it. Not even our science teacher, and he knew the Jedi language Fortran. So I expect it became just another paperweight in the headmaster's office.Go Forth and COMPILE :https://en.m.wikipedia.org/wiki/Jupiter_Ace

author: bd139
author_rank: Super Contributor
timestamp: February 05, 2021, 11:21:52 pm
content: On and off. Nothing serious. It’s a thing of beauty though.Worth pointing out CollapseOS as well which is a Forth implementation of “minimal computing to bring civilisation up again”. Mostly because it’s just about the only software platform that is manageable in one’s head:https://collapseos.org/

author: Stray Electron
author_rank: Super Contributor
timestamp: February 06, 2021, 12:01:39 am
content: I have the Forth ROM for a HP-71 but never used it. I also have Charles Moore's PolyForth for the IBM PC and I used that way back in the day but it's a self booting 5 1/4" floppy disk so it would be difficult, if not impossible, to use it today. Unless I dug my old IBM PC out of the closet and if it still runs.Two friends of mine, Bob Shannon and Steve Robertson, wrote a primitive but extensible OS for the HP-1000 computer in Forth.

author: gnuarm
author_rank: Super Contributor
timestamp: February 06, 2021, 12:33:28 am
content: Quote from: james_s on February 05, 2021, 09:39:08 pmI believe that is open boot which is based on the Forth concept.Forth is a collection of words (functions). Programs are written by stringing words together with all parameters passed on an explicit stack. This removes a lot of the syntax and overhead making it practical to include the compiler in even tiny MCUs. The compiler functions are available to be used by application programs, for example parsing input numbers and words. It can be pretty easy to work with and tested interactively.I've written a program to manage a test fixture and provide data to the Windows paste buffer so the operator can paste it into a spread sheet rather than have to copy it. Otherwise my Forth code has all been for internal functions in MCUs for various tasks.

author: gnuarm
author_rank: Super Contributor
timestamp: February 06, 2021, 12:39:40 am
content: Quote from: Stray Electron on February 06, 2021, 12:01:39 amForth has come a long way since then. Charles Moore has written booted machine level Forths for the PC that he uses to design chips. One was the GA144 with 144 processors all running at peak rates of 700 MIPS. It's not a typical massive CPU as each processor node hasverylimited memory and is intended to be used more like the logic blocks in an FPGA. I refer to the chip as a FPPA, Field Programmable Processor Array.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 07, 2021, 01:16:09 am
content: There is a regular here who is a long-time user of Forth. He'll probably be able to tell you a few things if he gets a chance.Apart from the Jupiter Ace (which was pretty much as bad as a ZX81but with Forth instead of Basic), there was this oddity, the Canon Cat, a much more interesting (but obviously more expensive, clearly not in the same league) machine, not well known, the OS of which was written in Forth.https://en.wikipedia.org/wiki/Canon_Cat

author: gnuarm
author_rank: Super Contributor
timestamp: February 07, 2021, 04:03:00 am
content: The Cannon Cat rings a bell. I expect I've heard of it in the Forth newsgroup.My interests are more along the lines of current use in embedded programming. I guess I'm curious as to how many (or how few) users of Forth there are in the world outside of the Forth newsgroup and SVFIG.

author: BitsnBytes
author_rank: Contributor
timestamp: February 07, 2021, 07:02:26 am
content: 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.Regards.

author: gnuarm
author_rank: Super Contributor
timestamp: February 07, 2021, 07:07:24 am
content: Quote from: BitsnBytes on February 07, 2021, 07:02:26 amInteresting that you claim C "outshines" Forth for bare metal programming when you acknowledge never using it.I was specifically referring to running on a small embedded target. I guess these days people consider a rPi to be a small embedded target. Or are you talking about targets like a CM0 ARM or an 8 bit PIC?

author: BitsnBytes
author_rank: Contributor
timestamp: February 07, 2021, 09:55:03 am
content: Quote from: gnuarm on February 07, 2021, 07:07:24 amYeah I am talking about bare metal programming. 8-bit, 16-bit, 32-bit microcontrollers. ARM based too like STM32.Am I wrong? Is Forth better than C?Sorry I don't know much about Forth, actually I have biased opinion about C...

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: February 07, 2021, 04:18:57 pm
content: Quote from: BitsnBytes on February 07, 2021, 09:55:03 amIn 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).In C, pushing/popping the stack is hidden from the programmer but the executable code the compiler generates will typically push values onto the stack prior to calling the appropriate routine.However, at the CPU's register level, C closely resembles the metal, as it were. Forth doesn't. Indeed, in some ways, the only way that Forth directly maps to the underlying processor is through the bit length of the word used.The stack/RPN concept can be extremely powerful. It is neither better nor worse than C. It's different. I am aware than some implementations of Forth exist as usable from within compilers for other languages, such as how many C/C++ compilers can accommodate assembler.

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: February 07, 2021, 04:30:47 pm
content: Quote from: SiliconWizard on February 07, 2021, 01:16:09 amWhat was wrong with a GBP99 computer that gave millions of teens access to something they could only otherwise dream about. All of the ZX-81's peculiarities (and even more so for the ZX-80) forced you to be very creative with your programming. You'll notice this question about Forth as pulled quite a few people like me out of the wood work (i.e., learning programming on cheap computers as teens in the UK in the early 1980s).

author: gnuarm
author_rank: Super Contributor
timestamp: February 07, 2021, 07:19:56 pm
content: Quote from: BitsnBytes on February 07, 2021, 09:55:03 amUntil "better" is defined I don't know how to answer that question. I use Forth because of the simplicity of operation on the target. Most target processors have enough memory to host the development tool. Since Forth is interactive that means only needing a PC to act as a terminal and file storage. Word definitions (subroutines) are typically one or a very few lines and so can be written and debugged interactively at the terminal interface.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. In another thread someone was talking about conventional languages being easier to debug than HDLs because you can single step on the target. I can't think of a less effective tool for debugging.But I'm not looking to debate which language is better. I was just asking how many are familiar with it and/or use it. I'm trying to gauge the amount of interest in discussing it.Forth is based on a virtual machine that is stack based, so the language uses RPN. That alone throws most people and so they never learn the more interesting bits of the language. So I'm not looking to proselytize or convert. That is far too uphill a climb for my tastes. Speaking of tastes, I'm ready for something to eat.

author: gnuarm
author_rank: Super Contributor
timestamp: February 07, 2021, 07:34:01 pm
content: Quote from: JohnnyMalaria on February 07, 2021, 04:18:57 pmI would not say the RPN notation is what makes Forth "powerful" really. What it does is to relieve the language of the burden of explicit operands along with the burden of the required syntax and typing.When designing FPGAs in the 90's I learned VHDL because I was working with the US government, rather than Verilog which is more popular with the comms industry. VHDL could not be any more opposite from Forth in requiring EVERYTHING to be explicit (talk about typing burden!) It is functional for me however, because the debugging environments are so different. With HDL simulations are used to test the design where every signal can be easily probed. So the REPL method works through simulation. In Forth it is explicit in that the code can be compiled on the target, run on the target and the result examined on the target. (Print in REPL doesn't need to be literal and can be examining a signal in simulation, reading a result in interactive execution or reaching a breakpoint and examining a variable in emulation).I just find the use of a debugger on a target to be a bit more awkward and another thing to learn, manage, kept up to date and to go wrong. With Forth everything that can go wrong is built into the language. lol

author: thinkfat
author_rank: Unknown
timestamp: February 07, 2021, 08:08:21 pm
content: I vaguely remember coding a Mandelbrot demo on a C64 35 years ago. To see if it was any faster than the built in Basic.

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: February 07, 2021, 08:14:20 pm
content: Quote from: gnuarm on February 07, 2021, 07:34:01 pmThe stack/RPN combination, not just RPNper se.

author: gnuarm
author_rank: Super Contributor
timestamp: February 07, 2021, 11:00:40 pm
content: Quote from: JohnnyMalaria on February 07, 2021, 08:14:20 pmOk, to me that is the enabler that allows the tool to be easily implemented and resident on a small target. But it is these aspects that make the language useful to me. Without the interactive command line it's just another quirky language to me.There are many words that users write that are not RPN and in fact the language has many words that are not RPN. For example VALUE is used for a variable with syntax of just using the variable name to return the value and using TO with the variable name to assign the value. With the word VARIABLE the address is returned and the words @ and ! are used to read the value or to write the value.

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: February 07, 2021, 11:04:31 pm
content: Um, okay. I wasn't really expecting a debate on my opinion. The combination of a stack-oriented programming mentality and the RPN that fits naturally with it is a powerful feature that makes Forth what it is. That's all.

author: gnuarm
author_rank: Super Contributor
timestamp: February 07, 2021, 11:54:13 pm
content: Ok, sorry if I seemed argumentative. Thanks for your comments.

author: helius
author_rank: Super Contributor
timestamp: February 08, 2021, 02:17:32 am
content: 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.

author: rfclown
author_rank: Frequent Contributor
timestamp: February 08, 2021, 03:04:02 am
content: Quote from: BitsnBytes on February 07, 2021, 07:02:26 amToday'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

author: gnuarm
author_rank: Super Contributor
timestamp: February 08, 2021, 05:06:48 am
content: Quote from: helius on February 08, 2021, 02:17:32 amI 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 Threecreates 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 asopr1 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.QuoteYes, 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 08, 2021, 05:20:56 am
content: Quote from: rfclown on February 08, 2021, 03:04:02 amWhen you have MB of memory Forth's size advantage is not so important.QuoteFrom 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.QuoteYeah, 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.QuoteYeah, 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.

author: retiredfeline
author_rank: Frequent Contributor
timestamp: February 08, 2021, 05:27:44 am
content: There is an active project putting Forth in off the shelf STM8 based gadgets:https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgetsI 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.

author: DiTBho
author_rank: Super Contributor
timestamp: February 08, 2021, 05:40:48 am
content: It may not be perfect, but Forth may be implemented on my graphic pocket calculator in order to interactively manage the sensor-port

author: gnuarm
author_rank: Super Contributor
timestamp: February 08, 2021, 06:09:32 am
content: Quote from: retiredfeline on February 08, 2021, 05:27:44 amI'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.

author: BitsnBytes
author_rank: Contributor
timestamp: February 08, 2021, 05:07:09 pm
content: QuoteIt'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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 08, 2021, 05:33:06 pm
content: 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

author: gnuarm
author_rank: Super Contributor
timestamp: February 09, 2021, 01:01:40 am
content: Quote from: BitsnBytes on February 08, 2021, 05:07:09 pmMany 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.

author: iMo
author_rank: Super Contributor
timestamp: February 09, 2021, 11:59:51 am
content: I've been always a big fan of the ForthContributed 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:Mecrisp-Ice 1.2ok.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 piF# (f#) _f# F.S fd abort" FVARIABLE FCONSTANT >FLOAT -trailing flfrac flexp flint fdigit? flgoodfsign FSQRT d< FE. FS. (E.) R. F. (F.) fsplit F~ F/ F* FMAX FMIN FROUND FLOOR F= F< F- F+ tnegFROT FNIP FPICK FOVER FSWAP FALIGNED FALIGN FABS F0> F0< F0= F0<> FSIGN? F! F@ FLOATS FLOAT+ S>FF>D D>F FNEGATE FDROP FDUP FDEPTH FCLEAR SET-PRECISION PRECISION F2/ F2* normalize fshift >exp1ftemp' expx2 expx1 m1sto m1get fmove 'e2 'e1 'm3 'm2 'm1 longdiv *norm lstemp t+ t2/ t2* sign>expexp>sign frshift ud2/ d2/ du< ferror &esign &sign &unsign mxdig bicl ftemp fstak fsp digits -byfpbyfp fpmxst see seec disasm-step memstamp alu. name. disasm-cont disasm-$ insight .s dump newcornerstone save erase spiwe waitspi m*/ t/ t* 2r@ 2r> 2>r tnegate 2constant 2variable timer1 randomrandombit tickshh ticksh ticksl now ms endcase endof of case s" within pad unused ." mod / /mod moveu.r .r d.r rtype u. . d. ud. (d.) #> #s # sign hold <# hld BUF BUF0 pick roll spaces */ */mod fm/modsm/rem sgn constant variable m* >body create repeat while else <= >= u<= u>= (  ['] eint? dinteint load spi> >spi spix idle xor! bic! bis! quit evaluate refill accept number \ char ' postponeliteral 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.141593e0print pi/1.23456e-775;2.544706e775

author: westfw
author_rank: Super Contributor
timestamp: February 10, 2021, 03:54:25 am
content: QuoteExcept 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...

author: gnuarm
author_rank: Super Contributor
timestamp: February 10, 2021, 06:09:39 am
content: Quote from: westfw on February 10, 2021, 03:54:25 amAs 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.

author: westfw
author_rank: Super Contributor
timestamp: February 10, 2021, 10:08:17 am
content: QuoteAh. 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 notThe Way That Things Are Done, any more. And with good reason.QuoteThat depends on the architecture. Some architectures can have one or both arguments in memory. (old, not-very-fast architectures, perhaps, but still...)Code:;; 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.

author: cgroen
author_rank: Unknown
timestamp: February 10, 2021, 10:27:24 am
content: 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).

author: gnuarm
author_rank: Super Contributor
timestamp: February 10, 2021, 10:47:59 am
content: Quote from: westfw on February 10, 2021, 10:08:17 amHow 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!

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 10, 2021, 02:44:00 pm
content: Quote from: westfw on February 10, 2021, 03:54:25 amYeah, 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.

author: helius
author_rank: Super Contributor
timestamp: February 10, 2021, 09:24:08 pm
content: Quote from: SiliconWizard on February 10, 2021, 02:44:00 pmOpinions 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.

author: bd139
author_rank: Super Contributor
timestamp: February 10, 2021, 10:49:35 pm
content: 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!

author: iMo
author_rank: Super Contributor
timestamp: February 10, 2021, 11:17:45 pm
content: 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

author: tszaboo
author_rank: Super Contributor
timestamp: February 10, 2021, 11:36:14 pm
content: Quote from: rfclown on February 08, 2021, 03:04:02 amActually, 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.

author: iMo
author_rank: Super Contributor
timestamp: February 10, 2021, 11:42:33 pm
content: Quote from: NANDBlog on February 10, 2021, 11:36:14 pmYou 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..

author: helius
author_rank: Super Contributor
timestamp: February 10, 2021, 11:51:28 pm
content: Quote from: NANDBlog on February 10, 2021, 11:36:14 pmAlso 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 11, 2021, 12:15:59 am
content: Quote from: imo on February 10, 2021, 11:42:33 pmActually 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.htmlYou need to search about a bit and there are lots of resources for Forth.

author: gnuarm
author_rank: Super Contributor
timestamp: February 11, 2021, 12:29:30 am
content: Quote from: imo on February 10, 2021, 11:17:45 pmWhile 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.

author: westfw
author_rank: Super Contributor
timestamp: February 11, 2021, 12:56:43 am
content: 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?")QuoteYou'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.phpOr... Here's a blinky demo from mecrisp for MPS430:Code:\ 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!begin1 P1OUT cxor!60000 0 do loopkey? 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" thanCode: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...)QuoteQuoteSo, 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?QuoteQuoteFailing 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.QuoteDitto. And deadly. "Forth code is hard to share."QuoteTrue 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.)QuoteSomewhat 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.QuoteForth 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.)

author: JagV12
author_rank: Contributor
timestamp: February 11, 2021, 02:46:02 am
content: Forth - How many know about and use it? Well, I use my HP48 every day and love itDoes that count ?

author: gnuarm
author_rank: Super Contributor
timestamp: February 11, 2021, 05:05:41 am
content: Quote from: westfw on February 11, 2021, 12:56:43 amYou 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.QuoteWhen 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.QuoteWhat 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.QuoteDid 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.QuoteSounds like you found something you like about Forth.QuoteThat's the sort of logic that would ban autos because someone used one to run through a crowd of people.QuoteSorry, 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.QuoteI 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.QuoteReally? 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...

author: iMo
author_rank: Super Contributor
timestamp: February 11, 2021, 08:13:07 am
content: Quote from: gnuarm on February 11, 2021, 12:15:59 amWell, 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 andwork interactivelywith the fpga's fabric.. An example ishere, for example..

author: dolbeau
author_rank: Regular Contributor
timestamp: February 11, 2021, 10:15:59 am
content: Quote from: gnuarm on February 06, 2021, 12:33:28 amYes, 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 canget 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.forthto expose devices to the PROM in OpenBoot 2.x Sun systems...)

author: gnuarm
author_rank: Super Contributor
timestamp: February 11, 2021, 02:26:02 pm
content: Quote from: imo on February 11, 2021, 08:13:07 amI 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.

author: tszaboo
author_rank: Super Contributor
timestamp: February 11, 2021, 05:27:48 pm
content: Quote from: helius on February 10, 2021, 11:51:28 pmYes, and the BMW M3 is only faster than a Pontiac Aztec for a reason know as "They put a better engine in it"

author: iMo
author_rank: Super Contributor
timestamp: February 11, 2021, 05:49:48 pm
content: Quote from: gnuarm on February 11, 2021, 02:26:02 pm.. and those could be the final words in this thread

author: westfw
author_rank: Super Contributor
timestamp: February 11, 2021, 11:26:13 pm
content: QuoteWell, 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 11, 2021, 11:39:25 pm
content: Quote from: westfw on February 11, 2021, 11:26:13 pmPlease 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 11, 2021, 11:49:37 pm
content: Quote from: westfw on February 11, 2021, 11:26:13 pmTECO? 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2021, 12:46:42 am
content: Quote from: gnuarm on February 09, 2021, 01:01:40 amI'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):WordTOS in a registerPure stack in memoryAdvantage+TOS = TOS + 0;SP++1 = 1 + 0;SP++regdropTOS = 0;SP++SP++memdup--SP; 0 = TOS--SP; 0 = 1regswapT = TOS; TOS = 0; 0 = TT1 = 0; T2 = 1; 0 = T2; 1 = T1regover--SP; 0 = 1; 1 = TOS--SP; T = 2; 0 = 2 = 1; 1 = TregnipSP++1 = 0; SP++regtuck--SP; 0 = TOS; TOS = 1--SP; 0 = 2equalrotT = 0; 0 = 1; 1 = TOS; TOS = TT = 0; 0 = 1; 1 = 2; 2 = TregThe 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 12, 2021, 01:11:38 am
content: Quote from: brucehoult on February 12, 2021, 12:46:42 amYou 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2021, 01:16:00 am
content: Quote from: gnuarm on February 12, 2021, 01:11:38 amNo.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++". 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 12, 2021, 01:29:09 am
content: Quote from: brucehoult on February 12, 2021, 01:16:00 amYou 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 compilerisyour application. Then I guess you just live in the rabbit hole and don't worry about it. Rabbits can be very accommodating. : )

author: techman-001
author_rank: Frequent Contributor
timestamp: February 12, 2021, 02:09:12 am
content: Quote from: gnuarm on February 05, 2021, 05:02:45 pmHi 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:: RCC_CR_HSIRDY? ( -- 1|0 ) 1 bit RCC_CR bit@ ; \ RCC_CR_HSIRDY, Internal High Speed clock ready flagA 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:RCC_CR. $03035183P H HL P C S S H HL L S E E S S HR L S B R E I SD O O Y D O| HSICAL | | R IY 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|00 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 1I 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' ;-)

author: helius
author_rank: Super Contributor
timestamp: February 12, 2021, 03:22:05 am
content: Quote from: westfw on February 11, 2021, 12:56:43 amHooks 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.htmlIn 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 callingdlopen().QuoteAn 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2021, 03:31:55 am
content: Quote from: gnuarm on February 12, 2021, 01:29:09 amNo. These are two DIFFERENT things:1) always keeping exactly the top two stack elements in registers2) 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.

author: helius
author_rank: Super Contributor
timestamp: February 12, 2021, 03:49:45 am
content: Quote from: brucehoult on February 12, 2021, 03:31:55 amIs 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2021, 04:38:35 am
content: Quote from: helius on February 12, 2021, 03:49:45 amFORTH 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 12, 2021, 06:23:28 am
content: Quote from: helius on February 12, 2021, 03:22:05 amhttps://xkcd.com/378/

author: gnuarm
author_rank: Super Contributor
timestamp: February 12, 2021, 06:25:40 am
content: Quote from: brucehoult on February 12, 2021, 03:31:55 amYes, 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2021, 06:40:04 am
content: Quote from: gnuarm on February 12, 2021, 06:25:40 amAs 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.

author: helius
author_rank: Super Contributor
timestamp: February 13, 2021, 12:03:26 am
content: Quote from: brucehoult on February 12, 2021, 04:38:35 amOne 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 callFADD, the operation isperformed on FP valueswhether they are the intended data or not. This mirrors assembler. The second case is a consistency check that Forth certainly can perform (thedepthword exists). Whether you require that check or not is subject to various practical considerations.Quote from: brucehoult on February 12, 2021, 04:38:35 amI 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.

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2021, 01:32:09 pm
content: Quote from: helius on February 13, 2021, 12:03:26 amExactly right.QuoteIndeed so.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 13, 2021, 05:31:33 pm
content: I was also replying to the original question. Namely, why I personally do not (in my case) use Forth or wouldn't consider using it. I was not trying to discourage anyone from doing so. Now if some of my points are not exact, I'm absolutely willing to reconsider them. Let's see:Quote from: westfw on February 11, 2021, 12:56:43 amMy point exactly. Internal data structures were a bizarre point for showing Forth has data structures. Those are not directly available to the programmer for structuring your data. Dictionaries allow you to define "words" (which are an idiomatic way of calling subroutines/functions/procedures). What else can you do with them?I've read a few things on implementing data structures in Forth, and as far as I've seen, it's all dynamic. One may argue that the same approach holds for a handful of other non-statically-typed languages. The drawbacks and benefits can be debated to no end, but to me, it looks like a good way of making code less readable, almost unverifiable statically, and easy to shoot yourself in the foot with. Of course it's partly opinion here, although this has been discussed and studied for quite a long time, and I'm sure you can find proponents of purely dynamic typing even for safety-critical applications. And this thread is probably not the right place for debating about static vs. dynamic typing in general, I'm just exposing points why *I* personally wouldn't consider Forth (other than out of historical interest.)As to my other point - saying that all your code lives in a "flat" world - there may be partly a lack of deep knowledge of Forth from my side. You can have several dictionaries, as I've been told here, but can you use several dictionaries simultaneously in a given program? Can you call "words" from another dictionary within words from a given dictionary? If so, please give a short example of how to do this, I'm curious (really!) If not, then that was my point. You could argue that the same holds for other non-modular languages such as C, which only has one namespace (if you omit oddities such as separate namespaces for structs and unions). But even in such languages, you have the ability to make some functions(/procedures/....) 'static' or 'private', meaning you can isolate them relatively. Is there a similar feature in Forth? This is not meant as a contest at all, or a language flame war. Just questions.Now for both points above, if anyone knowledgeable in Forth can provide short examples that would show that things are much "better" than I make them look, I'll be genuinely happy to have a look.

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2021, 09:07:34 pm
content: Not FORTH, but use of multiple dictionaries is common in PostScript.There is a stack of current dictionaries which names are automatically looked up in. "load" and "store" operators search the dictionary stack for the name. "def" creates a new name in the topmost dictionary. You can also use "put" and "get" to load and store things in explicitly named dictionaries i.e. a reference to them is taken from the (normal, not dictionary) stack.Dictionaries are used for local variables in functions, or even in a loop. Many functions start with something like "10 dict begin", where the 10 is the initial size of the dictionary hash table. Dictionaries are used for Object-Oriented programming. For example a font is a dictionary. The name "a" in the font dictionary is a function that draws the letter "a".

author: gnuarm
author_rank: Super Contributor
timestamp: February 13, 2021, 09:46:43 pm
content: Quote from: SiliconWizard on February 13, 2021, 05:31:33 pmWow! I'm no expert, but I'm familiar with Forth enough to know there is no limit to what you can do with data structures in Forth. I think the issue is you are accustomed to limiting yourself to whatever the language directly provides. Forth provides the base for creating structures like other languages. The big difference is this is all extensible in Forth. +FIELD is used to create arbitrary sized fields.From the language standard document.Code:10.6.2.0135+FIELD“plus-field”FACILITY EXT( n1 n2 “⟨spaces⟩name” – – n3 )Skip leading space delimiters. Parse name delimited by a space. Create a definition forname with the execution semantics defined below. Return n3 = n1 + n2 where n1 is theoffset in the data structure before +FIELD executes, and n2 is the size of the data to beadded to the data structure. n1 and n2 are in address units.name Execution: ( addr1 – – addr2 )Add n1 to addr1 giving addr2.See: 10.6.2.0763 BEGIN-STRUCTURE, 10.6.2.1336 END-STRUCTURE,10.6.2.0893 CFIELD:, 10.6.2.1518 FIELD:, 12.6.2.1517 FFIELD:,12.6.2.2206.40 SFFIELD:, 12.6.2.1207.40 DFFIELD:, A.10.6.2.0135 +FIELD.Here is info on some field words.Code:A.10.6.2.1518FIELD:Create an aligned single-cell field in a data structure.The various xFIELD: words provide for different alignment and size allocation.The xFIELD: words could be defined as:: FIELD:( n1 "name" -- n2 ; addr1 -- addr2 )ALIGNED 1 CELLS +FIELD ;: CFIELD:( n1 "name" -- n2 ; addr1 -- addr2 )1 CHARS +FIELD ;: FFIELD:( n1 "name" -- n2 ; addr1 -- addr2 )FALIGNED 1 FLOATS +FIELD ;: SFFIELD: ( n1 "name" -- n2 ; addr1 -- addr2 )SFALIGNED 1 SFLOATS +FIELD ;: DFFIELD: ( n1 "name" -- n2 ; addr1 -- addr2 )DFALIGNED 1 DFLOATS +FIELD ;I'm not going to go into the discussion of static vs. dynamic variables. I have no use for splitting such hairs.The standard committee does try to keep Forth as a one size fits all language while some users prefer a split approach, one language for embedded work and another language for desktop type applications. What I use Forth for does not require optimal efficiency or memory usage or anything else other than convenience to the programmer, me. So it is fine as is. I am very happy with the capabilities it has and the tremendous effectiveness I have in using it.