-
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?
-
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. :)
-
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/ (http://mecrisp.sourceforge.net/)
-
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.
-
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.
-
Isn't Forth the built in language in the ROM of Sun workstations?
Yes, it is (never used it though).
Postscript is also "related" to Forth, in that it is also a stack-oriented language.
-
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
-
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/
-
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.
-
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.
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.
-
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.
Forth 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 has very limited 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.
-
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 ZX81 :P but 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
-
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.
-
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.
-
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.
Interesting 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?
-
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?
Yeah 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... :P
-
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?
Yeah 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... :P
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).
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.
-
pretty much as bad as a ZX81
What 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).
-
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?
Yeah 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... :P
Until "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.
-
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.
I 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
-
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.
-
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.
I would not say the RPN notation is what makes Forth "powerful" really.
The stack/RPN combination, not just RPN per se.
-
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.
I would not say the RPN notation is what makes Forth "powerful" really.
The stack/RPN combination, not just RPN per se.
Ok, 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.
-
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.
-
Ok, sorry if I seemed argumentative. Thanks for your comments.
-
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.
-
I have never used Forth why?
The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.
Today's youth. Thinking Python/RPi stuff is efficient embedded stuff.
I worked at a company where the embeded guy (a contractor) used FORTH. It was a medical product (neurostimulator). When he retired the company found another FORTH programmer to continue the work. While the new guy was very good, and I would recommend him to anyone (Leon Wagner of FORTH Inc), it troubled me that if we lost him, it might not be easy to replace him. If it was my company, I would have chosen to use C initialy, mainly for the ease in finding/replacing programmers. I looked at FORTH, but I'm put off with the readability of the code. I can write C in a way that I can come back years later and figure out what I did. I couldn't even get started with FORTH without pondering every line. Maybe I'm just dull. It seems to be very efficient resource wise.
FORTH was the first high level language written for the RCA 1802 (COSMAC), and was done by the programmer I know. The 1802 was used in some spacecraft like Galileo and Magellan. They are sparce with resources on spacecraft (no Python there).
I recently ran across a cool project where someone made a computer out of logic chips (no processor) that ran FORTH.
http://www.aholme.co.uk/Mk1/Architecture.htm (http://www.aholme.co.uk/Mk1/Architecture.htm)
-
All the words are "RPN" if that means that you can write their stack effect (which you can for all words). Sometimes it will be a "compiling" stack effect with words taken from the parser stack (as with VARIABLE), but I'll argue that's still RPN.
I don't know if it is worth arguing nomenclature, but some things in Forth are not RPN. Maybe VALUE is not the best example. The part of VALUE that is not RPN is reading the name of the value item from the input stream following the word VALUE. That is like any other compiled language.
3 VALUE Three
creates a new word initializing the value to 3. As you can see the name is not on the stack when the word VALUE is encountered. There are words that operate on strings with their descriptors on the stack as address and length. Other types of strings are counted with the count appearing as the first item in the array. These work with the stack.
String definitions are not RPN themselves. Declaring a string is read from the input after the word that starts it.
." string contents"
Assemblers written in Forth are a good example. Early Forth assemblers had very different assembly syntax to be easier to write. They would appear as
opr1 opr2 opcode ,
The operands were words that returned the register id for example and the opcode was a word that accepted the two operands from the stack and combined them with the numeric opcode to produce the instruction on the stack. The comma is a Forth word to put the word from the stack into the dictionary which is where the code would be compiled for the time being.
Now the non-RPN assemblers written in Forth use the same syntax as any other tool (for the opcode and operands anyway), but the various aspects of using commas and such are different. Still, they are no longer RPN.
While it is not really hard to get used to RPN, many don't like it (the lazy ones perhaps?) and many Forthers are willing to accommodate that.
The system is powerful. You can put hooks on defered words, redefining what they do at runtime. This can be very convenient and is one of the real elegant things about OpenBoot/OpenFirmware.
Yes, I've used that to redirect I/O between the console for debugging and a serial port for runtime work or even a socket connection to another window.
One of the issues that people don't like is that many things are only provided in a raw form. You often have to do a fair amount of work to create your own libraries. Compared to the many libraries that can be found for many languages that would appear to be inconvenient. But I view all but the most often used libraries with a cautious eye. They are like footprint libraries for layout. The footprints may be fine, but if they have a bug I don't want to find out after they are used in a design. So I create my own footprints and I tend to write my own libraries.
-
I have never used Forth why?
The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.
Today's youth. Thinking Python/RPi stuff is efficient embedded stuff.
When you have MB of memory Forth's size advantage is not so important.
I worked at a company where the embeded guy (a contractor) used FORTH. It was a medical product (neurostimulator). When he retired the company found another FORTH programmer to continue the work. While the new guy was very good, and I would recommend him to anyone (Leon Wagner of FORTH Inc), it troubled me that if we lost him, it might not be easy to replace him. If it was my company, I would have chosen to use C initialy, mainly for the ease in finding/replacing programmers. I looked at FORTH, but I'm put off with the readability of the code. I can write C in a way that I can come back years later and figure out what I did. I couldn't even get started with FORTH without pondering every line. Maybe I'm just dull. It seems to be very efficient resource wise.
From his reputation, Leon Wagner would be hard to replace, but I'm not sure you'd really need someone of his skill level to do most programming.
This is one reason why people aren't interested in Forth. I get the same argument against using FPGAs. Lots more C programmers than HDL.
FORTH was the first high level language written for the RCA 1802 (COSMAC), and was done by the programmer I know. The 1802 was used in some spacecraft like Galileo and Magellan. They are sparce with resources on spacecraft (no Python there).
Yeah, Forth was used on one of the asteroid landers, the name escapes me at the moment. In space stuff what is most important is that the tools be qualified as well as the hardware. That's an expensive process, so they tend to continue using things for a long time.
I recently ran across a cool project where someone made a computer out of logic chips (no processor) that ran FORTH.
http://www.aholme.co.uk/Mk1/Architecture.htm (http://www.aholme.co.uk/Mk1/Architecture.htm)
Yeah, using discrete SSI components is not so common, but stack processors on FPGAs are very common. I've done some myself. I think it was a confluence around 2000 when FPGAs started being big enough and a lot cheaper so the idea of a CPU on the FPGA wasn't so crazy. A stack processor can be very small and fast.
-
There is an active project putting Forth in off the shelf STM8 based gadgets: https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets
I know about Forth, even have books on it from decades ago, and have wanted for a long time to play with it, not so much for the small footprint (costs very little to buy a uC with more memory), but the interactive nature of coding and debugging. Maybe I'll get a round tuit one day.
-
It may not be perfect, but Forth may be implemented on my graphic pocket calculator in order to interactively manage the sensor-port :D
-
There is an active project putting Forth in off the shelf STM8 based gadgets: https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets
I know about Forth, even have books on it from decades ago, and have wanted for a long time to play with it, not so much for the small footprint (costs very little to buy a uC with more memory), but the interactive nature of coding and debugging. Maybe I'll get a round tuit one day.
I'm not so familiar with eForth. Mecrisp is available for a wide range of devices. I think I mentioned that below. TMS430 chips and many ARM varieties along with FPGA processors including custom and RISC-V. Mecrisp is very prolific.
-
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.
-
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
-
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've been always a big fan of the Forth :) Contributed a little bit to FlashForth (pic18/24/33), Amforth (atmega32, 328, 1284), Mecrisp Forth (stm32F1/4, FPGA). Latest demonstration is the MF port to the Lattice iCE40UP5k fpga (with 48bit floating point math as a "because we can" example, btw) in 3 free IDEs.
Programming Forth means creating your "own dictionary" by writing many small "words". The new words are always using the previous words in the dictionary. The dictionary lives on-the-chip, and grows up with the new words added. That is so simple.. :)
All above Forths have got the complete dev system on-the-chip, thus you will need only a serial terminal in order to write your programs (aka "new words"). The performance is similar to a compiled C or a bit better sometimes.. The required ram/flash is usually much smaller than a C build..
For example the MF on a 16bit j1a modded core, running inside the iCE40UP5k fpga (BTW, the entire "dictionary" below occupies 11828 bytes):
Mecrisp-Ice 1.2
ok.
words falog f** flog fln (log) fraction integer> >integer lbase epsilon fexp ^fraction
^integer (!) d>u d0< fpow fatan2 facos fasin (fasin) fatan dom2|3 dom3 dom2 (fatan) (taylor2)
2degrees ftan fsincos fcos fsin >range -taylor +taylor (taylor) >taylor rad>deg deg>rad e pi
F# (f#) _f# F.S fd abort" FVARIABLE FCONSTANT >FLOAT -trailing flfrac flexp flint fdigit? flgood
fsign FSQRT d< FE. FS. (E.) R. F. (F.) fsplit F~ F/ F* FMAX FMIN FROUND FLOOR F= F< F- F+ tneg
FROT FNIP FPICK FOVER FSWAP FALIGNED FALIGN FABS F0> F0< F0= F0<> FSIGN? F! F@ FLOATS FLOAT+ S>F
F>D D>F FNEGATE FDROP FDUP FDEPTH FCLEAR SET-PRECISION PRECISION F2/ F2* normalize fshift >exp1
ftemp' expx2 expx1 m1sto m1get fmove 'e2 'e1 'm3 'm2 'm1 longdiv *norm lstemp t+ t2/ t2* sign>exp
exp>sign frshift ud2/ d2/ du< ferror &esign &sign &unsign mxdig bicl ftemp fstak fsp digits -byfp
byfp fpmxst see seec disasm-step memstamp alu. name. disasm-cont disasm-$ insight .s dump new
cornerstone save erase spiwe waitspi m*/ t/ t* 2r@ 2r> 2>r tnegate 2constant 2variable timer1 random
randombit tickshh ticksh ticksl now ms endcase endof of case s" within pad unused ." mod / /mod move
u.r .r d.r rtype u. . d. ud. (d.) #> #s # sign hold <# hld BUF BUF0 pick roll spaces */ */mod fm/mod
sm/rem sgn constant variable m* >body create repeat while else <= >= u<= u>= ( [char] ['] eint? dint
eint load spi> >spi spix idle xor! bic! bis! quit evaluate refill accept number \ char ' postpone
literal abort rdrop r@ r> >r hex binary decimal unloop j i +loop loop ?do leave do recurse does>
until again begin then if ahead ; exit :noname : ] [ immediate foldable sliteral s, compile, c, ,
allot parse parse-name source 2! 2@ cmove> cmove fill sfind align aligned words here tib init forth
>in base state /string type count .x .x2 bl cr space c! c@ emit key key? emit? um/mod * um* d2* d0=
m+ s>d dabs d- dnegate d+ depth io@ io! nip over dup swap u< < = invert not or and xor - + ! 2/ 2*
cells abs bounds umax umin max min 2over 2swap +! 2dup ?dup 2drop tuck -rot rot true false drop u>
0> 0< > 0<> <> cell+ 0= rdepth @ 1- negate 1+ arshift rshift lshift execute ok.
ok.
here . 11828 ok.
unused . 3532 ok.
ok.
pi fs. 3.141593e0 ok.
pi f# 1.23456e-775 f/ fs. 2.544706e775 ok.
The last 2 lines above converted to "Basic":
print pi;
3.141593e0
print pi/1.23456e-775;
2.544706e775
-
In one regard, Forth is closely to the bare metal of the CPU than C - namely, the use of the stack.
Except that Forth runs fine on chips without any hardware stack instructions, and frequently uses separate stacks for data and instruction paths...
Yeah, I'm somewhat familiar with Forth. Read the magazine articles and most of the book (back when it was The Book!) Typed in the 8080 version for a simulator, implemented a few subsets, even wrote some raw postscript for a job, sort-of.It always struck me as elegant in its minimal forms - you can write a small and useful interpreter for a very small chip indeed. You can implement neat little "interactive" systems. It's closer to "metal" than most interpreters. And it is interesting for those reasons.
But it also strikes me has rapidly becoming unwieldy, unreadable, and ... unnecessary in a more modern world, like it was purposely ignoring decades worth of "software engineering best practices" WRT things like code readability, editing, data structuring, file systems, libraries, source code management, strong typing, weak typing (I mean, separate operators for 16bit add and 32bit add, but no checking that the arguments match?)
I mean, it's possible that I've just missed all the "modernization" of Forth (good Postscript loos OK), but it certainly seems to be the old-style versions that show up more often...
-
But it also strikes me has rapidly becoming unwieldy, unreadable, and ... unnecessary in a more modern world, like it was purposely ignoring decades worth of "software engineering best practices" WRT things like code readability, editing, data structuring, file systems, libraries, source code management, strong typing, weak typing (I mean, separate operators for 16bit add and 32bit add, but no checking that the arguments match?)
I mean, it's possible that I've just missed all the "modernization" of Forth (good Postscript loos OK), but it certainly seems to be the old-style versions that show up more often...
As a user of Forth and VHDL which are pretty much polar opposites regarding strong typing, I like the lack of strong typing in Forth and like the strong typing in VHDL.
In Forth I don't find the lack of strong typing to be an issue because the code is written and tested in small pieces where you don't really need so much protection. I only wish I could write and test VHDL interactively like I can with Forth. However, since it is not interactive I find the strong typing helps to assure the design is solid with much less debugging unforeseen errors.
So the real issue is what are you willing to give up in the way of protection from shooting yourself in the foot compared to being able to dance the night away while developing and debugging code? Since it would be hard, but not impossible as some Forths have typing, to include data checks for stack data while retaining the ease of use of an interpreted language, I prefer the interactivity.
-
In Forth ... the code is written and tested in small pieces
Ah. Another bit that is contrary to modern practices. :-)
Forth also has "problems" with ROM-heavy systems and Harvard architectures.
Don't get me wrong. I spent about 6 years of my career programming almost exclusively in Assembly Language, and I liked it. But ... it's not The Way That Things Are Done, any more. And with good reason.
even in assembly language we have to perform arithematic operation on operands when they are in general purpose registers.
That depends on the architecture. Some architectures can have one or both arguments in memory. (old, not-very-fast architectures, perhaps, but still...) ;; 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.
-
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).
-
In Forth ... the code is written and tested in small pieces
Ah. Another bit that is contrary to modern practices. :-)
Forth also has "problems" with ROM-heavy systems and Harvard architectures.
How is that exactly? By ROM heavy do you mean RAM challenged? I can't say I'm familiar with the various techniques, but I'm pretty sure people have found ways. One method I use is to develop on a version of the chip with more RAM. It works, then final test on the version to be shipped, and ship!
-
But it also strikes me has rapidly becoming unwieldy, unreadable, and ... unnecessary in a more modern world, like it was purposely ignoring decades worth of "software engineering best practices" WRT things like code readability, editing, data structuring, file systems, libraries, source code management, strong typing, weak typing (I mean, separate operators for 16bit add and 32bit add, but no checking that the arguments match?)
Yeah, same thought here.
As much as I appreciate Forth's simplicity and relative elegance, it's IMHO pretty much unmaintainable, can't exhibit any form of data structure or structured code really, no type check, almost no possibiliy of static analysis (if there is, I'd be curious to take a look!), everything in a whole flat "world"... Yeah. As to using "stacks" as the core memory management, it has pros and cons. Would take quite a while to fully detail that.
OTOH, the interpreters/compilers are so simple to write that it's much easier to make them bug-free.
-
IMHO...can't exhibit any form of data structure or structured code really, ... everything in a whole flat "world"
Opinions are fine, but these statements are errors.
You can have multiple dictionaries for different purposes in Forth. The "whole flat world" is in your imagination, not an actual requirement.
-
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!
-
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 :D
-
I have never used Forth why?
The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.
Today's youth. Thinking Python/RPi stuff is efficient embedded stuff.
Actually, an average python programmer could write better and faster programs, than 90% of C programmers, because they can harness the power of the best C programmers.
Take a sorting algorithm for example. Just think about for a second, how do you write the fastest sorting algorithm in C or Forth? You know the answer?
I tell you how you sort a variable called array in python: array.sort()
It doesnt look much, right? In the background it calls a sorting algorithm written by the best computer scientists ... in C.
But take something else for example. Matrix multiplications. It takes literally 4 lines of code, to multiply the matrix on your GPU, which is a thousand times faster, rather than the CPU. Try doing this in Forth. Or Fortran. I hope you remember those memory addresses for PCI-e memory transfers, and you are good at setting up DMAs.
-
..
Take a sorting algorithm for example. Just think about for a second, how do you write the fastest sorting algorithm in C or Forth? You know the answer?
I tell you how you sort a variable called array in python: array.sort()
It doesnt look much, right? In the background it calls a sorting algorithm written by the best computer scientists ... in C.
But take something else for example. Matrix multiplications. It takes literally 4 lines of code, to multiply the matrix on your GPU, which is a thousand times faster, rather than the CPU. Try doing this in Forth. Or Fortran. I hope you remember those memory addresses for PCI-e memory transfers, and you are good at setting up DMAs.
You can do the same in Forth, provided you have got the right "word" handy.. :D
PS: and yes - that is the major issue with Forth I see - sharing or publishing "libraries" is not common in the Forth community..
-
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.
-
..
Take a sorting algorithm for example. Just think about for a second, how do you write the fastest sorting algorithm in C or Forth? You know the answer?
I tell you how you sort a variable called array in python: array.sort()
It doesnt look much, right? In the background it calls a sorting algorithm written by the best computer scientists ... in C.
But take something else for example. Matrix multiplications. It takes literally 4 lines of code, to multiply the matrix on your GPU, which is a thousand times faster, rather than the CPU. Try doing this in Forth. Or Fortran. I hope you remember those memory addresses for PCI-e memory transfers, and you are good at setting up DMAs.
You can do the same in Forth, provided you have got the right "word" handy.. :D
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 (https://www.taygeta.com/fsl/docs/NobleArchive.html)
You need to search about a bit and there are lots of resources for Forth.
-
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 :D
While your initial statement is true, the apparent implication is not. What you call "trickery" is actually aspects of the language that other languages simply don't have. For example, you can define an array to simply use whatever offset you hand it with the repercussion of memory violations from bad offsets. Or you can define arrays that do bounds checking. You can define arrays that tell you how much of the array is in use (like character string lengths). You can define an array that keeps a running total of the elements.
What's even better is you can define words to use to define these different types of arrays. So one word to define the new array type. Then use that word to define the arrays to be used.
You might call that "trickery". The tool doesn't get in the way of doing crazy things. The tool doesn't get in the way of doing fantastic things either.
In VHDL I wanted to add an operator to my program (yes, I consider VHDL code to be a program). Seems I can create functions and have them treated the same as any other function in the system with overloading for various types. But not for operators. I can define an existing operator for new data types, but "read my lips, no new operators" to paraphrase senior Bush. That got in the way of what I was trying to do.
I only wish I could design FPGAs at the hardware level with Forth.
-
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 (https://www.pascal-programming.info/lesson11.php)
Or... Here's a blinky demo from mecrisp for MPS430:
\ 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
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.)
-
Forth - How many know about and use it? Well, I use my HP48 every day and love it :) Does that count ?
-
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 (https://www.pascal-programming.info/lesson11.php)
Or... Here's a blinky demo from mecrisp for MPS430:
\ 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
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... :-//
-
You can do the same in Forth, provided you have got the right "word" handy.. :D
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 (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 (https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB), for example..
-
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 (https://standards.ieee.org/standard/1275-1994.html), 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 (http://www.sunhelp.org/pipermail/rescue/2020-July/142265.html) ) There's an OSS implementation as well, OpenBIOS (https://github.com/openbios/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 (https://github.com/rdolbeau/SBusFPGA/blob/main/sbus-to-ztex/prom.forth) to expose devices to the PROM in OpenBoot 2.x Sun systems...)
-
You can do the same in Forth, provided you have got the right "word" handy.. :D
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 (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.
-
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"
-
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 :D
-
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.
-
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.
-
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.
-
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.
|
-
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.
-
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.
-
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. : )
-
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.
: 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.
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. :wtf:
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' ;-)
-
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 (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.
-
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.
-
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.
-
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.
-
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/
-
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.
-
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.
-
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.
-
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.
-
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:
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 (https://www.pascal-programming.info/lesson11.php)
My 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.
-
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".
-
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:
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 (https://www.pascal-programming.info/lesson11.php)
My 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?
Wow! 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.
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 for
name with the execution semantics defined below. Return n3 = n1 + n2 where n1 is the
offset in the data structure before +FIELD executes, and n2 is the size of the data to be
added 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.
A.10.6.2.1518
FIELD:
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.