14 ms·

My history with Forth and stack machines (2010)

80 points by sph 3y ago

optimalsolver 3y ago
I always recommend the book Starting Forth [0]. It has the most charming illustrations I've ever seen in a text book. [0] https://www.forth.com/starting-forth/ https://www.forth.com/starting-forth/
- DonHopkins 3y ago
  Also Thinking Forth by Leo Brodie is an excellent style and philosophy book! https://thinking-forth.sourceforge.net/ https://thinking-forth.sourceforge.net/ http://prdownloads.sourceforge.net/thinking-forth/thinking-forth.pdf?download http://prdownloads.sourceforge.net/thinking-forth/thinking-f...
optimalsolver 3y ago
Is there any reason stack-based CPUs fell out of favor? I'm fascinated by RTX2010 [0], a radiation-hardened processor which uses Forth and has been deployed on several space missions. [0] https://en.wikipedia.org/wiki/RTX2010 https://en.wikipedia.org/wiki/RTX2010
- boesboes 3y ago
  I've been reading into this today coincidentally. It seems the main idea was that register based machines are faster, mostly due to the use of local variables in many languages mapping to register and memory latency when the stack is in memory. But that seems to be false based on more recent research. This is a good read on the subject: https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... Also, check out the GA144: https://www.greenarraychips.com/ https://www.greenarraychips.com/ Also, it's not clear a super scalar stack machine would be possible. So it might not be suitable for replacing x86 soon ;)
  - compressedgas 3y ago
    > Also, it's not clear a super scalar stack machine would be possible. The "Boost: Berkeley's Out-of-Order Stack Thingy" (Steve Sinha, Satrajit Chatterjee and Kaushik Ravindran) [1] effectively translates stack code into RISC as part of instruction decoding and issue. This is similar to how "Design of a Superscalar Processor Based on Queue Machine Computation Model" (Shusuke Okamoto, Hitoshi Suzuki, Atusi Maeda, Masahiro Sowa) [2] does the same thing but for a queue machine instead of a stack machine. [1]: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=0366820530b662bd1c3a912720ce23795862d1ba https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d... [2]: https://ieeexplore.ieee.org/document/799499 https://ieeexplore.ieee.org/document/799499
    - ithkuil 3y ago
      Is the "belt" of the Mill CPU a queue architecture or is a queue architecture something else?
      - compressedgas 3y ago
        Yes. The Mill's belt is a queue. The Mill is a queue machine.
    - boesboes 3y ago
      Interesting, thank you! More for the reading list :)
  - kragen 3y ago
    the summary of laforest's dissertation says that a small stack machine is much faster (than a presumably in-order MIPS) "for deeply nested or recursive code", but "worse for iterative code" quite aside from the new results it presents, it seems to be a much more comprehensive answer to the question of why stack machines fell out of favor than i've seen before
    - fouc 3y ago
      I've definitely seen that explanation before. I remain slightly skeptical, but that's mostly because I secretly hope stack machines could "win" some day.
- jasonwatkinspdx 3y ago
  Compared to a register machine a stack machine needs to execute extra instructions to shuffle the stack around. If you tried to do something clever to make this superscalar you'd end up with something very much like shadow registers anyhow. I too found Charle's Moore's cpu designs interesting. One possibility I thought about for a bit was a VLIW stack hybrid, where you'd have bundles of say 8 stack instructions each executing concurrently in their own lane, and some instructions for moving values between lanes. It'd be a weird thing to program for, but potentially quite fast for how minimal it'd be.
  - sph 3y ago
    Here's Chuck Moore talking about the 144-core CPUs his startup is developing: https://youtu.be/0PclgBd6_Zs https://youtu.be/0PclgBd6_Zs That's an incredible design I would love to get my paws on.
    - jasonwatkinspdx 3y ago
      Oh thanks, I'll check that out. I was musing about this stuff back when reading Hennessy and Patterson in the early 00's. Moore's homepage was really interesting and inspiring, that someone could work idiosyncratically and largely individually and actually get chips to tape out. Cool to hear he's still going strong.
    - kragen 3y ago
      you can just order a ga144 from them last i checked
- sph 3y ago
  WASM is a stack based "CPU" and arguably the future of the Web. So is Python's. I think also Java and Erlang, but don't quote me on that. A stack based CPU is very easy to implement (or rather, registers are very complex hardware-wise) and a stack-based VM is relatively easy to optimise for a register CPU. Seems to me registers are a fancy hardware implementation detail, that software at higher abstraction can and should avoid unless maximum performance is required. It was surprising for me to learn recently that on modern x86 CPUs, named registers actually reference hidden, dynamically allocated physical registers, a bit like virtual memory is an indirection layer over physical memory. It's levels of indirection all the way down...
  - jasonwatkinspdx 3y ago
    So the basic principle is that stack machines have smaller instructions, but require extra instructions to shuffle values around on the stack. This is why register machines won out with hardware, and stack machines are popular for virtual machine intermediate representations (that get compiled or JIT down to register code in the end on basically all machines today). If you wanna learn about how register renaming works, look into Tomasulo's algorithm. State of the art chips are a lot more complex, but that's a good historic introduction to the fundamental ideas.
  - runlaszlorun 3y ago
    I’ve been wrestling with WASM bytecode and text format of and on for the last couple years for want of doing something assembly-ish but not wanting to write off doing it for the web. Personally, I’d say it’s at least as much of a register machine as a stack machine and ways in which it is one vs the other at times sure had me running in circles. I’ve seen plenty of quotes about how it’s not supposed to be a real assembly, how you’re not supposed to deal with its text format or bytecode, and how it and its documentation are for compiler writers not typical programmers. Which is exactly the take that I think is so wrong with our status quo of opaque, overly abstracted technologies that are highly optimized in their parts yet so disappointing in the whole. As a Forth substitute, I was sorely disappointed. I did learn a lot in my wanderings, and what WebAssembly is mostly is a an implementation to run a C architecture. Which is pretty much what it came from. Not that I’m against that, but I sure ran in circles trying to make it more Forth-like. And given it’s raison d’etre to be more performant vs Javascript it seems to be faster in some benchmarks while slower in others. I think this is more a testament about how optimized V8 and its brethren are then a slam on WebAssembly.
- jacquesm 3y ago
  I worked for a company that was building a prototype using the predecessor (the 'NOVIX'), which was incredibly fast for the day.
  - DonHopkins 3y ago
    I really wanted one of those! I held one in my hands one time when I was visiting the MIT-AI Lab -- it was Norman Margolus's, who made the CAM-6 with Tommaso Toffoli, which was programmed in Forth. He wouldn't let me have it, but he let my friend and I borrow a CAM-6 for a weekend science fiction convention to trip out on. https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=34561910 https://news.ycombinator.com/item?id=34561910 Rudy Rucker writes about his CAM-6 in the CelLab manual: http://www.fourmilab.ch/cellab/manual/chap5.html http://www.fourmilab.ch/cellab/manual/chap5.html Computer science is still so new that many of the people at the cutting edge have come from other fields. Though Toffoli holds degrees in physics and computer science, Bennett's Ph.D. is in physical chemistry. And twenty-nine year old Margolus is still a graduate student in physics, his dissertation delayed by the work of inventing, with Toffoli, the CAM-6 Cellular Automaton Machine. After watching the CAM in operation at Margolus's office, I am sure the thing will be a hit. Just as the Moog synthesizer changed the sound of music, cellular automata will change the look of video. I tell this to Toffoli and Margolus, and they look unconcerned. What they care most deeply about is science, about Edward Fredkin's vision of explaining the world in terms of cellular automata and information mechanics. Margolus talks about computer hackers, and how a successful program is called “a good hack.” As the unbelievably bizarre cellular automata images flash by on his screen, Margolus leans back in his chair and smiles slyly. And then he tells me his conception of the world we live in. “The universe is a good hack.” [...] Margolus and Toffoli's CAM-6 board was finally coming into production around then, and I got the Department to order one. The company making the boards was Systems Concepts of San Francisco; I think they cost $1500. We put our order in, and I started phoning Systems Concepts up and asking them when I was going to get my board. By then I'd gotten a copy of Margolus and Toffoli's book, Cellular Automata Machines, and I was itching to start playing with the board. And still it didn't come. Finally I told System Concepts that SJSU was going to have to cancel the purchase order. The next week they sent the board. By now it was August, 1987. The packaging of the board was kind of incredible. It came naked, all by itself, in a plastic bag in a small box of styrofoam peanuts. No cables, no software, no documentation. Just a three inch by twelve inch rectangle of plastic—actually two rectangles one on top of the other—completely covered with computer chips. There were two sockets at one end. I called Systems Concepts again, and they sent me a few pages of documentation. You were supposed to put a cable running your graphics card's output into the CAM-6 board, and then plug your monitor cable into the CAM-6's other socket. No, Systems Concepts didn't have any cables, they were waiting for a special kind of cable from Asia. So Steve Ware, one of the SJSU Math&CS Department techs, made me a cable. All I needed then was the software to drive the board, and as soon as I phoned Toffoli he sent me a copy. Starting to write programs for the CAM-6 took a little bit of time because the language it uses is Forth. This is an offbeat computer language that uses reverse Polish notation. Once you get used to it, Forth is very clean and nice, but it makes you worry about things you shouldn't really have to worry about. But, hey, if I needed to know Forth to see cellular automata, then by God I'd know Forth. I picked it up fast and spent the next four or five months hacking the CAM-6. The big turning point came in October, when I was invited to Hackers 3.0, the 1987 edition of the great annual Hackers' conference held at a camp near Saratoga, CA. I got invited thanks to James Blinn, a graphics wizard who also happens to be a fan of my science fiction books. As a relative novice to computing, I felt a little diffident showing up at Hackers, but everyone there was really nice. It was like, “Come on in! The more the merrier! We're having fun, yeeeeee-haw!” I brought my AT along with the CAM-6 in it, and did demos all night long. People were blown away by the images, though not too many of them sounded like they were ready to a) cough up $1500, b) beg Systems Concepts for delivery, and c) learn Forth in order to use a CAM-6 themselves. A bunch of the hackers made me take the board out of my computer and let them look at it. Not knowing too much about hardware, I'd imagined all along that the CAM-6 had some special processors on it. But the hackers informed me that all it really had was a few latches and a lot of fast RAM memory chips.
- kragen 3y ago
  register machines need to run about half as many instructions on average to do the same thing, which means that at the same clock speed a 1-cycle-per-clock cpu will go about twice as fast with a register instruction set. countering that is that the stack machine doesn't need multiplexers on the inputs to the alu, so it may actually be able to run at a higher clock speed if those multiplexers were part of the critical path, and the stack machine will occupy less silicon area, so you may be able to have more of them (but usually ram takes a lot more area than your cpu) for out-of-order and superscalar processing, register machines have an advantage in that you can more easily have successive instructions that don't interfere, simply by not using the same registers. generally in a stack machine instruction it's hard to avoid using the result of the previous instruction; you need an extra instruction to do it (`over` or `swap` or something) but i suspect it's partly just path-dependence: koopman's new wave of stack machines were already struggling upwind against 30 years of ibm 360, intel 8080, dec pdp-11, motorola 68000, dg nova, sun/fujitsu sparc, etc., all register machines, and so a rich store of knowledge had built up about them in compiler backends, assembly programmers, and cpu designers. maybe if chuck had designed the rtx2010 in 01973 instead of 01988 the story would have been different maybe worth noting that all of the jvm, microsoft's clone of it (the cil), and wasm (as sph pointed out) are stack-based, and arm for a while had a 'jazelle' instruction set which interpreted many jvm bytecodes directly (trapping to software for more complex ones), so in a sense stack-based programs are more widespread now than they ever were before; that's what you see inside a .class file. they just are usually translated into some other instruction set before execution
  - kragen 3y ago
    in https://news.ycombinator.com/item?id=37025644 https://news.ycombinator.com/item?id=37025644 boesboes links to https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... which is a bachelor's of independent studies thesis from several years back which covers the history of stack machines in considerable detail, including, most fascinatingly, zuse's z4, with its 64-word memory, 8-bit instruction tape, and 2-level stack also several people have pointed out that the stack machines most commonly used in practice, including the ones i mentioned above, are hybrids; they have architectural registers (often called local variables) but you have to copy them onto the stack to operate on them
riidom 3y ago
For people getting a 503: https://archive.li/xh0aq https://archive.li/xh0aq
ks2048 3y ago
People interested in Forth might want to also check out PostScript (similar and stack-based). I recently wrote a blog post with a very brief PostScript tutorial and an example program translated line-by-line to Python https://kenschutte.com/postscript-vs-python/ https://kenschutte.com/postscript-vs-python/
- optimalsolver 3y ago
  Just fyi, typo on this line: >it this case, it’s a built-in
- whartung 3y ago
  Well, my favorite stack based language was RPL on the HP. Simply because it fit well in the scope of the environment that it was used. It was really easy to develop and debug on the calculator (I know many did very large projects working with editors on the PC, but I did all my work on the machine itself). It lacked any kind of composite structure outside of lists and arrays. No structs or records. But that was never a real barrier. It was just a nice, high level stack machine with a cool library and toolset.
  - runlaszlorun 3y ago
    As a big RPN and HP calc fan forever, and a recent Forth fan, I was a bit confused by my initial foray into RPL. It seemed like it allow infix notation and that threw me of at first glance. Did I bail to soon? I am a big stack machine convert and have had an HP RPN calc since 12.
    - whartung 3y ago
      The HP-48 certainly could do infix style calculations and formulas (the solvers work with these). But from the prompt it’s not particularly natural. Algebraic entry is a second class citizen. But do look at RPL. Anything that lets you push anonymous functions onto the stack can’t be all bad.
  - shagie 3y ago
    My favorite stack based language is dc. It's also the oldest language still found on Unix systems, predating even C (the original version was written in B on a PDP-11 - even before it had an assembler). https://www.cs.dartmouth.edu/~doug/reader.pdf https://www.cs.dartmouth.edu/~doug/reader.pdf > Almost everybody in the group has done languages. Thompson and Ritchie built assemblers from scratch. On the tiny PDP-7 the assembler was supplemented by tmg, Doug McIlroy’s version of Bob McClure’s compiler-compiler. Using it Thompson wrote B, the evolutionary link between Martin Richards’s (Cambridge University) BCPL and C. The PDP-11 assembler, a desk calculator dc, and B itself were written in B to bootstrap the system to the PDP-11. Because it could run before the disk had arrived, dc—not the assembler—became the first language to run on our PDP-11. Soon revised to handle arbitrary- precision numbers (v1), dc was taken over by Bob Morris and Lorinda Cherry. It now ranks as the senior language on UNIX systems.
Corsome 3y ago
while(true) { switch(*ip) { //arithmetics (+,-,*...): case PLUS: ds.push(ds.pop() + ds.pop()); ++ip; //stack manipulation (drop,swap,rot...): case DROP: ds.pop(); ++ip; ... Hmm... shouldn't each case contain a break? It doesn't seem like a fall through is a good idea here.
- DonHopkins 3y ago
  Mitch Bradley's CForth has an infinite while loop as the inner interpreter with a switch statement inside, that uses a macro "#define next continue" to jump to the next instruction in the infinite while loop, instead of break. https://github.com/MitchBradley/cforth/blob/master/src/cforth/forth.c#L91 https://github.com/MitchBradley/cforth/blob/master/src/cfort... Mitch's CForth is about as efficient (and well designed and refined) a Forth interpreter you can possibly implement in portable C. Mitch's OpenFirmware is a more traditional industrial strength Forth implementation, extremely advanced, feature rich, and well designed, that runs on many different processors and hardware, has assemblers for different CPUs, and a metacompiler that supports many different CPUs, word sizes, byte orders, threading techniques, top level interactive control structures, headerless code, machine independent bytecode, read-only firmware, portable device drivers, hardware and driver configuration, and many hardware platforms. https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/openfirmware This is an implementation of Open Firmware, a processor-independent firmware design. Open Firmware is specified by IEEE 1275-1994, Standard for Boot (Initialization, Configuration) Firmware. The IEEE standard designation lapsed in 1999, when the Open Firmware working group declined to go through the rather time-consuming IEEE reaffirmation process, but the design lives on. This implementation was written primarily by Mitch Bradley, the original author of Open Firmware. The bulk of the recent development was done at Firmworks by Bradley and colleagues. It traces its roots back to the original Open Boot firmware implementation that Bradley developed at Sun Microsystems in the late 80s and early 90s. That in turn had roots in Forthmacs, a Forth programming language implementation developed and marketed during the early 80s by Bradley Forthware. And Forthmacs, in turn, owes a debt of gratitude to the public domain Forth implementations F83, developed by Michael Perry, and MVP Forth, by Glen Haydon. Lilian Walter wrote the USB stack. https://news.ycombinator.com/item?id=29279022 https://news.ycombinator.com/item?id=29279022 DonHopkins on Nov 19, 2021 | parent | context | favorite | on: Forth vs Lisp The inner interpreter of Mitch Bradley's portable and efficient CForth is simply implemented with a big switch statement, in the function called "inner_interpreter". The C compiler typically compiles that code with the big switch statement into an efficient jump table, behind the scenes. https://github.com/MitchBradley/cforth/blob/master/src/cforth/forth.c#L72 https://github.com/MitchBradley/cforth/blob/master/src/cfort... Properly speaking, that's a token threaded interpreter, since it switches on token numbers in the code field, instead of indirecting function through pointers to the C equivalent of "code" words. https://en.wikipedia.org/wiki/Threaded_code#Token_threading https://en.wikipedia.org/wiki/Threaded_code#Token_threading https://news.ycombinator.com/item?id=27484426 https://news.ycombinator.com/item?id=27484426 DonHopkins on June 12, 2021 | root | parent | next [–] From https://news.ycombinator.com/item?id=21823081 https://news.ycombinator.com/item?id=21823081 I wrote malloc.fth for Mitch Bradley's ForthMacs, which ended up in OpenFirmware: https://github.com/openbios/openfirmware/blob/master/ofw/core/ofwcore.fth#L3453 https://github.com/openbios/openfirmware/blob/master/ofw/cor... [...] https://news.ycombinator.com/item?id=21822840 https://news.ycombinator.com/item?id=21822840 DonHopkins on Dec 18, 2019 | parent | context | favorite | on: Thoughts on Forth Programming Here's the interview with Mitch Bradley saved on archive.org: https://web.archive.org/web/20120118132847/http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-firmware-olpc/ https://web.archive.org/web/20120118132847/http://howsoftwar... I've previously posted some stuff about Mitch Bradley -- I have used various versions of his ForthMacs / CForth / OpenFirmware systems, and I was his summer intern at Sun in '87! Mitch is an EXTREMELY productive FORTH programmer! He explains that FORTH is a "Glass Box": you just have to memorize its relatively simple set of standard words, and then you can have a complete understanding and full visibility into exactly how every part of the system works: there is no mysterious "magic", you can grok and extend every part of the system all the way down to the metal. It's especially nice when you have a good decompiler / dissassembler ("SEE") like ForthMacs, CForth, and OpenFirmware do. https://news.ycombinator.com/item?id=9271644 https://news.ycombinator.com/item?id=9271644 [...]
systems_glitch 3y ago
I've started building a small desk clock project based on a Rockwell R65F11 embedded FORTH processor, in an effort to force myself to actually do a nontrivial project in FORTH. It's not progressing quickly, but it's also not a priority. Several folks whose opinions matter to me were big FORTH hackers in the late 70s thru the 90s, so I figure there must be something there worth hacking on!
hintymad 3y ago
Netflix's Altas, a telemetry services, uses a stack language for querying metrics. The language has a relatively steep learning curve, but once one groks it, it is surprisingly easy to use to compose complex OLAP queries.
- quag 3y ago
  If anyone else is interested, https://netflix.github.io/atlas-docs/overview/#stack-language https://netflix.github.io/atlas-docs/overview/#stack-languag... is the stack language for querying.
  - runlaszlorun 3y ago
    Interesting, I’ll check it out. One intersection insight I had with stack languages is that they might lend themselves to an AST-like visual approach. The tree <-> postfix duality was an interesting aha for me that I’d long forgotten since that sophomore data structures class. :)
  - knowledge-clay 3y ago
    This looks very similar to RRDTool's query language. Is this a fork, or was it just inspired by RRDTool?
    - hintymad 3y ago
      In that case, probably a fork, as Netflix used rrdtools extensively before Atlas.
LAC-Tech 3y ago
Anyone looked at WASM, especially its text code format? I feel like it so badly wants to look something like forth but they couldn't make themselves do it. It would be so much more concise.
- jasonwatkinspdx 3y ago
  They wanted to make it low friction to learn for their audience who are largely javascript programmers. I think it's a reasonable tradeoff even if I personally would prefer a more combinator style syntax.
  - runlaszlorun 3y ago
    Was that really the intent? I made a longer rant elsewhere in this thread but I sure got the impression it was really for compiler implementers and not for anyone really writing in it at all. It’s sort of a false Lisp and a false Forth when I really should have not been afraid of the ARM vs x86 split and brushed up on a real assembly. :)
    - jasonwatkinspdx 3y ago
      WASM grew out of the earlier asm.js, which was explicitly designed as a subset of javascript: http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/ The core idea there was to identify a subset of JS that was high performance on browsers and could be used as a compile target. WASM appeared because once asm.js got some momentum, people naturally asked "hey if browsers could implement just a couple extra things how much better could we make this?"
      - kragen 3y ago
        wasm isn't compatible with asm.js or with js tho they could have totally made it forthier if they thought that was a good idea, but their objective was rapid generation of efficient, secure code
        3y ago
dang 3y ago
Related: My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=26203518 https://news.ycombinator.com/item?id=26203518 - Feb 2021 (25 comments) My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=21153555 https://news.ycombinator.com/item?id=21153555 - Oct 2019 (33 comments) My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=8869150 https://news.ycombinator.com/item?id=8869150 - Jan 2015 (26 comments) My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=8146306 https://news.ycombinator.com/item?id=8146306 - Aug 2014 (17 comments) My History With Forth And Stack Machines - https://news.ycombinator.com/item?id=3963896 https://news.ycombinator.com/item?id=3963896 - May 2012 (11 comments)
1vuio0pswjnm7 3y ago
Found in yesterday's https://ftp.funet.fi https://ftp.funet.fi submission. 1984. Made with lex. https://ftp.funet.fi/pub/languages/forth/c-forth.tar.Z https://ftp.funet.fi/pub/languages/forth/c-forth.tar.Z
- DonHopkins 3y ago
  The most modern up-to-date version of Mitch Bradley's C-Forth is here: https://github.com/MitchBradley/cforth https://github.com/MitchBradley/cforth As Mitch's summer intern at Sun in 1987, I used CForth to make an interactive extension language for CADroid (a printed circuit design program from Lucasfilms that Sun used internally). https://uspto.report/TM/73486026 https://uspto.report/TM/73486026 Oh cool, the CADroid trademark's canceled -- that would be nice to recycle for a cellular automata robot!
kragen 3y ago
i think i finally got to the point where forth was usable for me in 02019 https://dercuano.github.io/notes/forth-assembling.html#addtoc_3 https://dercuano.github.io/notes/forth-assembling.html#addto... all it really took was for me to stop using stack manipulation operators and treat forth as an interactive user interface rather than a programming language
- sph 3y ago
  That's an incredible blog! I have two wishes now: that you would continue to write your notes because I've skimmed a few and they were deeply interesting to me, and that you would add an RSS feed, so I can add it to Feedbin. But in any case, thanks. Lot of interesting ideas in that article.
  - kragen 3y ago
    glad you like it! it's more a book than a blog; its contents are final and immutable, so an rss feed would be of very limited interest. the sequels so far are derctuo and dernocua
anta40 3y ago
My impression so far is (in general), Forth are practically limited to doing embedded/microcontroller development. For us, web/mobile/desktop app devs, beside: - 8th (https://8th-dev.com https://8th-dev.com) - Factor (https://factorcode.org https://factorcode.org) Any suggestion which implementation we should look for?
mud_dauber 3y ago
I spent a year at Harris Semi’s RTX group. A previous gig as a Forth programmer plus undergrad work in assembly programming came in handy. I really wish RTX had caught on with commercial clients, but the lack of tools made it tough for most folks.

80 points by sph 3y ago

I always recommend the book Starting Forth [0]. It has the most charming illustrations I've ever seen in a text book. [0] https://www.forth.com/starting-forth/ https://www.forth.com/starting-forth/

DonHopkins 3y ago
Also Thinking Forth by Leo Brodie is an excellent style and philosophy book! https://thinking-forth.sourceforge.net/ https://thinking-forth.sourceforge.net/ http://prdownloads.sourceforge.net/thinking-forth/thinking-forth.pdf?download http://prdownloads.sourceforge.net/thinking-forth/thinking-f...

optimalsolver 3y ago

Is there any reason stack-based CPUs fell out of favor? I'm fascinated by RTX2010 [0], a radiation-hardened processor which uses Forth and has been deployed on several space missions. [0] https://en.wikipedia.org/wiki/RTX2010 https://en.wikipedia.org/wiki/RTX2010

boesboes 3y ago
I've been reading into this today coincidentally. It seems the main idea was that register based machines are faster, mostly due to the use of local variables in many languages mapping to register and memory latency when the stack is in memory. But that seems to be false based on more recent research. This is a good read on the subject: https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... Also, check out the GA144: https://www.greenarraychips.com/ https://www.greenarraychips.com/ Also, it's not clear a super scalar stack machine would be possible. So it might not be suitable for replacing x86 soon ;)
- compressedgas 3y ago
  > Also, it's not clear a super scalar stack machine would be possible. The "Boost: Berkeley's Out-of-Order Stack Thingy" (Steve Sinha, Satrajit Chatterjee and Kaushik Ravindran) [1] effectively translates stack code into RISC as part of instruction decoding and issue. This is similar to how "Design of a Superscalar Processor Based on Queue Machine Computation Model" (Shusuke Okamoto, Hitoshi Suzuki, Atusi Maeda, Masahiro Sowa) [2] does the same thing but for a queue machine instead of a stack machine. [1]: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=0366820530b662bd1c3a912720ce23795862d1ba https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d... [2]: https://ieeexplore.ieee.org/document/799499 https://ieeexplore.ieee.org/document/799499
  - ithkuil 3y ago
    Is the "belt" of the Mill CPU a queue architecture or is a queue architecture something else?
    - compressedgas 3y ago
      Yes. The Mill's belt is a queue. The Mill is a queue machine.
  - boesboes 3y ago
    Interesting, thank you! More for the reading list :)
- kragen 3y ago
  the summary of laforest's dissertation says that a small stack machine is much faster (than a presumably in-order MIPS) "for deeply nested or recursive code", but "worse for iterative code" quite aside from the new results it presents, it seems to be a much more comprehensive answer to the question of why stack machines fell out of favor than i've seen before
  - fouc 3y ago
    I've definitely seen that explanation before. I remain slightly skeptical, but that's mostly because I secretly hope stack machines could "win" some day.
jasonwatkinspdx 3y ago
Compared to a register machine a stack machine needs to execute extra instructions to shuffle the stack around. If you tried to do something clever to make this superscalar you'd end up with something very much like shadow registers anyhow. I too found Charle's Moore's cpu designs interesting. One possibility I thought about for a bit was a VLIW stack hybrid, where you'd have bundles of say 8 stack instructions each executing concurrently in their own lane, and some instructions for moving values between lanes. It'd be a weird thing to program for, but potentially quite fast for how minimal it'd be.
- sph 3y ago
  Here's Chuck Moore talking about the 144-core CPUs his startup is developing: https://youtu.be/0PclgBd6_Zs https://youtu.be/0PclgBd6_Zs That's an incredible design I would love to get my paws on.
  - jasonwatkinspdx 3y ago
    Oh thanks, I'll check that out. I was musing about this stuff back when reading Hennessy and Patterson in the early 00's. Moore's homepage was really interesting and inspiring, that someone could work idiosyncratically and largely individually and actually get chips to tape out. Cool to hear he's still going strong.
  - kragen 3y ago
    you can just order a ga144 from them last i checked
sph 3y ago
WASM is a stack based "CPU" and arguably the future of the Web. So is Python's. I think also Java and Erlang, but don't quote me on that. A stack based CPU is very easy to implement (or rather, registers are very complex hardware-wise) and a stack-based VM is relatively easy to optimise for a register CPU. Seems to me registers are a fancy hardware implementation detail, that software at higher abstraction can and should avoid unless maximum performance is required. It was surprising for me to learn recently that on modern x86 CPUs, named registers actually reference hidden, dynamically allocated physical registers, a bit like virtual memory is an indirection layer over physical memory. It's levels of indirection all the way down...
- jasonwatkinspdx 3y ago
  So the basic principle is that stack machines have smaller instructions, but require extra instructions to shuffle values around on the stack. This is why register machines won out with hardware, and stack machines are popular for virtual machine intermediate representations (that get compiled or JIT down to register code in the end on basically all machines today). If you wanna learn about how register renaming works, look into Tomasulo's algorithm. State of the art chips are a lot more complex, but that's a good historic introduction to the fundamental ideas.
- runlaszlorun 3y ago
  I’ve been wrestling with WASM bytecode and text format of and on for the last couple years for want of doing something assembly-ish but not wanting to write off doing it for the web. Personally, I’d say it’s at least as much of a register machine as a stack machine and ways in which it is one vs the other at times sure had me running in circles. I’ve seen plenty of quotes about how it’s not supposed to be a real assembly, how you’re not supposed to deal with its text format or bytecode, and how it and its documentation are for compiler writers not typical programmers. Which is exactly the take that I think is so wrong with our status quo of opaque, overly abstracted technologies that are highly optimized in their parts yet so disappointing in the whole. As a Forth substitute, I was sorely disappointed. I did learn a lot in my wanderings, and what WebAssembly is mostly is a an implementation to run a C architecture. Which is pretty much what it came from. Not that I’m against that, but I sure ran in circles trying to make it more Forth-like. And given it’s raison d’etre to be more performant vs Javascript it seems to be faster in some benchmarks while slower in others. I think this is more a testament about how optimized V8 and its brethren are then a slam on WebAssembly.
jacquesm 3y ago
I worked for a company that was building a prototype using the predecessor (the 'NOVIX'), which was incredibly fast for the day.
- DonHopkins 3y ago
  I really wanted one of those! I held one in my hands one time when I was visiting the MIT-AI Lab -- it was Norman Margolus's, who made the CAM-6 with Tommaso Toffoli, which was programmed in Forth. He wouldn't let me have it, but he let my friend and I borrow a CAM-6 for a weekend science fiction convention to trip out on. https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=8860786 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=14469113 https://news.ycombinator.com/item?id=34561910 https://news.ycombinator.com/item?id=34561910 Rudy Rucker writes about his CAM-6 in the CelLab manual: http://www.fourmilab.ch/cellab/manual/chap5.html http://www.fourmilab.ch/cellab/manual/chap5.html Computer science is still so new that many of the people at the cutting edge have come from other fields. Though Toffoli holds degrees in physics and computer science, Bennett's Ph.D. is in physical chemistry. And twenty-nine year old Margolus is still a graduate student in physics, his dissertation delayed by the work of inventing, with Toffoli, the CAM-6 Cellular Automaton Machine. After watching the CAM in operation at Margolus's office, I am sure the thing will be a hit. Just as the Moog synthesizer changed the sound of music, cellular automata will change the look of video. I tell this to Toffoli and Margolus, and they look unconcerned. What they care most deeply about is science, about Edward Fredkin's vision of explaining the world in terms of cellular automata and information mechanics. Margolus talks about computer hackers, and how a successful program is called “a good hack.” As the unbelievably bizarre cellular automata images flash by on his screen, Margolus leans back in his chair and smiles slyly. And then he tells me his conception of the world we live in. “The universe is a good hack.” [...] Margolus and Toffoli's CAM-6 board was finally coming into production around then, and I got the Department to order one. The company making the boards was Systems Concepts of San Francisco; I think they cost $1500. We put our order in, and I started phoning Systems Concepts up and asking them when I was going to get my board. By then I'd gotten a copy of Margolus and Toffoli's book, Cellular Automata Machines, and I was itching to start playing with the board. And still it didn't come. Finally I told System Concepts that SJSU was going to have to cancel the purchase order. The next week they sent the board. By now it was August, 1987. The packaging of the board was kind of incredible. It came naked, all by itself, in a plastic bag in a small box of styrofoam peanuts. No cables, no software, no documentation. Just a three inch by twelve inch rectangle of plastic—actually two rectangles one on top of the other—completely covered with computer chips. There were two sockets at one end. I called Systems Concepts again, and they sent me a few pages of documentation. You were supposed to put a cable running your graphics card's output into the CAM-6 board, and then plug your monitor cable into the CAM-6's other socket. No, Systems Concepts didn't have any cables, they were waiting for a special kind of cable from Asia. So Steve Ware, one of the SJSU Math&CS Department techs, made me a cable. All I needed then was the software to drive the board, and as soon as I phoned Toffoli he sent me a copy. Starting to write programs for the CAM-6 took a little bit of time because the language it uses is Forth. This is an offbeat computer language that uses reverse Polish notation. Once you get used to it, Forth is very clean and nice, but it makes you worry about things you shouldn't really have to worry about. But, hey, if I needed to know Forth to see cellular automata, then by God I'd know Forth. I picked it up fast and spent the next four or five months hacking the CAM-6. The big turning point came in October, when I was invited to Hackers 3.0, the 1987 edition of the great annual Hackers' conference held at a camp near Saratoga, CA. I got invited thanks to James Blinn, a graphics wizard who also happens to be a fan of my science fiction books. As a relative novice to computing, I felt a little diffident showing up at Hackers, but everyone there was really nice. It was like, “Come on in! The more the merrier! We're having fun, yeeeeee-haw!” I brought my AT along with the CAM-6 in it, and did demos all night long. People were blown away by the images, though not too many of them sounded like they were ready to a) cough up $1500, b) beg Systems Concepts for delivery, and c) learn Forth in order to use a CAM-6 themselves. A bunch of the hackers made me take the board out of my computer and let them look at it. Not knowing too much about hardware, I'd imagined all along that the CAM-6 had some special processors on it. But the hackers informed me that all it really had was a few latches and a lot of fast RAM memory chips.
kragen 3y ago
register machines need to run about half as many instructions on average to do the same thing, which means that at the same clock speed a 1-cycle-per-clock cpu will go about twice as fast with a register instruction set. countering that is that the stack machine doesn't need multiplexers on the inputs to the alu, so it may actually be able to run at a higher clock speed if those multiplexers were part of the critical path, and the stack machine will occupy less silicon area, so you may be able to have more of them (but usually ram takes a lot more area than your cpu) for out-of-order and superscalar processing, register machines have an advantage in that you can more easily have successive instructions that don't interfere, simply by not using the same registers. generally in a stack machine instruction it's hard to avoid using the result of the previous instruction; you need an extra instruction to do it (`over` or `swap` or something) but i suspect it's partly just path-dependence: koopman's new wave of stack machines were already struggling upwind against 30 years of ibm 360, intel 8080, dec pdp-11, motorola 68000, dg nova, sun/fujitsu sparc, etc., all register machines, and so a rich store of knowledge had built up about them in compiler backends, assembly programmers, and cpu designers. maybe if chuck had designed the rtx2010 in 01973 instead of 01988 the story would have been different maybe worth noting that all of the jvm, microsoft's clone of it (the cil), and wasm (as sph pointed out) are stack-based, and arm for a while had a 'jazelle' instruction set which interpreted many jvm bytecodes directly (trapping to software for more complex ones), so in a sense stack-based programs are more widespread now than they ever were before; that's what you see inside a .class file. they just are usually translated into some other instruction set before execution
- kragen 3y ago
  in https://news.ycombinator.com/item?id=37025644 https://news.ycombinator.com/item?id=37025644 boesboes links to https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/LaForest_Eric.pdf?isAllowed=y&sequence=1 https://uwspace.uwaterloo.ca/bitstream/handle/10012/10810/La... which is a bachelor's of independent studies thesis from several years back which covers the history of stack machines in considerable detail, including, most fascinatingly, zuse's z4, with its 64-word memory, 8-bit instruction tape, and 2-level stack also several people have pointed out that the stack machines most commonly used in practice, including the ones i mentioned above, are hybrids; they have architectural registers (often called local variables) but you have to copy them onto the stack to operate on them

riidom 3y ago

For people getting a 503: https://archive.li/xh0aq https://archive.li/xh0aq

ks2048 3y ago

People interested in Forth might want to also check out PostScript (similar and stack-based). I recently wrote a blog post with a very brief PostScript tutorial and an example program translated line-by-line to Python https://kenschutte.com/postscript-vs-python/ https://kenschutte.com/postscript-vs-python/

optimalsolver 3y ago
Just fyi, typo on this line: >it this case, it’s a built-in
whartung 3y ago
Well, my favorite stack based language was RPL on the HP. Simply because it fit well in the scope of the environment that it was used. It was really easy to develop and debug on the calculator (I know many did very large projects working with editors on the PC, but I did all my work on the machine itself). It lacked any kind of composite structure outside of lists and arrays. No structs or records. But that was never a real barrier. It was just a nice, high level stack machine with a cool library and toolset.
- runlaszlorun 3y ago
  As a big RPN and HP calc fan forever, and a recent Forth fan, I was a bit confused by my initial foray into RPL. It seemed like it allow infix notation and that threw me of at first glance. Did I bail to soon? I am a big stack machine convert and have had an HP RPN calc since 12.
  - whartung 3y ago
    The HP-48 certainly could do infix style calculations and formulas (the solvers work with these). But from the prompt it’s not particularly natural. Algebraic entry is a second class citizen. But do look at RPL. Anything that lets you push anonymous functions onto the stack can’t be all bad.
- shagie 3y ago
  My favorite stack based language is dc. It's also the oldest language still found on Unix systems, predating even C (the original version was written in B on a PDP-11 - even before it had an assembler). https://www.cs.dartmouth.edu/~doug/reader.pdf https://www.cs.dartmouth.edu/~doug/reader.pdf > Almost everybody in the group has done languages. Thompson and Ritchie built assemblers from scratch. On the tiny PDP-7 the assembler was supplemented by tmg, Doug McIlroy’s version of Bob McClure’s compiler-compiler. Using it Thompson wrote B, the evolutionary link between Martin Richards’s (Cambridge University) BCPL and C. The PDP-11 assembler, a desk calculator dc, and B itself were written in B to bootstrap the system to the PDP-11. Because it could run before the disk had arrived, dc—not the assembler—became the first language to run on our PDP-11. Soon revised to handle arbitrary- precision numbers (v1), dc was taken over by Bob Morris and Lorinda Cherry. It now ranks as the senior language on UNIX systems.

Corsome 3y ago

while(true) { switch(*ip) { //arithmetics (+,-,*...): case PLUS: ds.push(ds.pop() + ds.pop()); ++ip; //stack manipulation (drop,swap,rot...): case DROP: ds.pop(); ++ip; ... Hmm... shouldn't each case contain a break? It doesn't seem like a fall through is a good idea here.

DonHopkins 3y ago
Mitch Bradley's CForth has an infinite while loop as the inner interpreter with a switch statement inside, that uses a macro "#define next continue" to jump to the next instruction in the infinite while loop, instead of break. https://github.com/MitchBradley/cforth/blob/master/src/cforth/forth.c#L91 https://github.com/MitchBradley/cforth/blob/master/src/cfort... Mitch's CForth is about as efficient (and well designed and refined) a Forth interpreter you can possibly implement in portable C. Mitch's OpenFirmware is a more traditional industrial strength Forth implementation, extremely advanced, feature rich, and well designed, that runs on many different processors and hardware, has assemblers for different CPUs, and a metacompiler that supports many different CPUs, word sizes, byte orders, threading techniques, top level interactive control structures, headerless code, machine independent bytecode, read-only firmware, portable device drivers, hardware and driver configuration, and many hardware platforms. https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/openfirmware This is an implementation of Open Firmware, a processor-independent firmware design. Open Firmware is specified by IEEE 1275-1994, Standard for Boot (Initialization, Configuration) Firmware. The IEEE standard designation lapsed in 1999, when the Open Firmware working group declined to go through the rather time-consuming IEEE reaffirmation process, but the design lives on. This implementation was written primarily by Mitch Bradley, the original author of Open Firmware. The bulk of the recent development was done at Firmworks by Bradley and colleagues. It traces its roots back to the original Open Boot firmware implementation that Bradley developed at Sun Microsystems in the late 80s and early 90s. That in turn had roots in Forthmacs, a Forth programming language implementation developed and marketed during the early 80s by Bradley Forthware. And Forthmacs, in turn, owes a debt of gratitude to the public domain Forth implementations F83, developed by Michael Perry, and MVP Forth, by Glen Haydon. Lilian Walter wrote the USB stack. https://news.ycombinator.com/item?id=29279022 https://news.ycombinator.com/item?id=29279022 DonHopkins on Nov 19, 2021 | parent | context | favorite | on: Forth vs Lisp The inner interpreter of Mitch Bradley's portable and efficient CForth is simply implemented with a big switch statement, in the function called "inner_interpreter". The C compiler typically compiles that code with the big switch statement into an efficient jump table, behind the scenes. https://github.com/MitchBradley/cforth/blob/master/src/cforth/forth.c#L72 https://github.com/MitchBradley/cforth/blob/master/src/cfort... Properly speaking, that's a token threaded interpreter, since it switches on token numbers in the code field, instead of indirecting function through pointers to the C equivalent of "code" words. https://en.wikipedia.org/wiki/Threaded_code#Token_threading https://en.wikipedia.org/wiki/Threaded_code#Token_threading https://news.ycombinator.com/item?id=27484426 https://news.ycombinator.com/item?id=27484426 DonHopkins on June 12, 2021 | root | parent | next [–] From https://news.ycombinator.com/item?id=21823081 https://news.ycombinator.com/item?id=21823081 I wrote malloc.fth for Mitch Bradley's ForthMacs, which ended up in OpenFirmware: https://github.com/openbios/openfirmware/blob/master/ofw/core/ofwcore.fth#L3453 https://github.com/openbios/openfirmware/blob/master/ofw/cor... [...] https://news.ycombinator.com/item?id=21822840 https://news.ycombinator.com/item?id=21822840 DonHopkins on Dec 18, 2019 | parent | context | favorite | on: Thoughts on Forth Programming Here's the interview with Mitch Bradley saved on archive.org: https://web.archive.org/web/20120118132847/http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-firmware-olpc/ https://web.archive.org/web/20120118132847/http://howsoftwar... I've previously posted some stuff about Mitch Bradley -- I have used various versions of his ForthMacs / CForth / OpenFirmware systems, and I was his summer intern at Sun in '87! Mitch is an EXTREMELY productive FORTH programmer! He explains that FORTH is a "Glass Box": you just have to memorize its relatively simple set of standard words, and then you can have a complete understanding and full visibility into exactly how every part of the system works: there is no mysterious "magic", you can grok and extend every part of the system all the way down to the metal. It's especially nice when you have a good decompiler / dissassembler ("SEE") like ForthMacs, CForth, and OpenFirmware do. https://news.ycombinator.com/item?id=9271644 https://news.ycombinator.com/item?id=9271644 [...]

systems_glitch 3y ago

I've started building a small desk clock project based on a Rockwell R65F11 embedded FORTH processor, in an effort to force myself to actually do a nontrivial project in FORTH. It's not progressing quickly, but it's also not a priority. Several folks whose opinions matter to me were big FORTH hackers in the late 70s thru the 90s, so I figure there must be something there worth hacking on!

hintymad 3y ago

Netflix's Altas, a telemetry services, uses a stack language for querying metrics. The language has a relatively steep learning curve, but once one groks it, it is surprisingly easy to use to compose complex OLAP queries.

quag 3y ago
If anyone else is interested, https://netflix.github.io/atlas-docs/overview/#stack-language https://netflix.github.io/atlas-docs/overview/#stack-languag... is the stack language for querying.
- runlaszlorun 3y ago
  Interesting, I’ll check it out. One intersection insight I had with stack languages is that they might lend themselves to an AST-like visual approach. The tree <-> postfix duality was an interesting aha for me that I’d long forgotten since that sophomore data structures class. :)
- knowledge-clay 3y ago
  This looks very similar to RRDTool's query language. Is this a fork, or was it just inspired by RRDTool?
  - hintymad 3y ago
    In that case, probably a fork, as Netflix used rrdtools extensively before Atlas.

LAC-Tech 3y ago

Anyone looked at WASM, especially its text code format? I feel like it so badly wants to look something like forth but they couldn't make themselves do it. It would be so much more concise.

jasonwatkinspdx 3y ago
They wanted to make it low friction to learn for their audience who are largely javascript programmers. I think it's a reasonable tradeoff even if I personally would prefer a more combinator style syntax.
- runlaszlorun 3y ago
  Was that really the intent? I made a longer rant elsewhere in this thread but I sure got the impression it was really for compiler implementers and not for anyone really writing in it at all. It’s sort of a false Lisp and a false Forth when I really should have not been afraid of the ARM vs x86 split and brushed up on a real assembly. :)
  - jasonwatkinspdx 3y ago
    WASM grew out of the earlier asm.js, which was explicitly designed as a subset of javascript: http://asmjs.org/spec/latest/ http://asmjs.org/spec/latest/ The core idea there was to identify a subset of JS that was high performance on browsers and could be used as a compile target. WASM appeared because once asm.js got some momentum, people naturally asked "hey if browsers could implement just a couple extra things how much better could we make this?"
    - kragen 3y ago
      wasm isn't compatible with asm.js or with js tho they could have totally made it forthier if they thought that was a good idea, but their objective was rapid generation of efficient, secure code
      - 3y ago

dang 3y ago

Related: My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=26203518 https://news.ycombinator.com/item?id=26203518 - Feb 2021 (25 comments) My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=21153555 https://news.ycombinator.com/item?id=21153555 - Oct 2019 (33 comments) My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=8869150 https://news.ycombinator.com/item?id=8869150 - Jan 2015 (26 comments) My history with Forth and stack machines (2010) - https://news.ycombinator.com/item?id=8146306 https://news.ycombinator.com/item?id=8146306 - Aug 2014 (17 comments) My History With Forth And Stack Machines - https://news.ycombinator.com/item?id=3963896 https://news.ycombinator.com/item?id=3963896 - May 2012 (11 comments)

1vuio0pswjnm7 3y ago

Found in yesterday's https://ftp.funet.fi https://ftp.funet.fi submission. 1984. Made with lex. https://ftp.funet.fi/pub/languages/forth/c-forth.tar.Z https://ftp.funet.fi/pub/languages/forth/c-forth.tar.Z

DonHopkins 3y ago
The most modern up-to-date version of Mitch Bradley's C-Forth is here: https://github.com/MitchBradley/cforth https://github.com/MitchBradley/cforth As Mitch's summer intern at Sun in 1987, I used CForth to make an interactive extension language for CADroid (a printed circuit design program from Lucasfilms that Sun used internally). https://uspto.report/TM/73486026 https://uspto.report/TM/73486026 Oh cool, the CADroid trademark's canceled -- that would be nice to recycle for a cellular automata robot!

kragen 3y ago

i think i finally got to the point where forth was usable for me in 02019 https://dercuano.github.io/notes/forth-assembling.html#addtoc_3 https://dercuano.github.io/notes/forth-assembling.html#addto... all it really took was for me to stop using stack manipulation operators and treat forth as an interactive user interface rather than a programming language

sph 3y ago
That's an incredible blog! I have two wishes now: that you would continue to write your notes because I've skimmed a few and they were deeply interesting to me, and that you would add an RSS feed, so I can add it to Feedbin. But in any case, thanks. Lot of interesting ideas in that article.
- kragen 3y ago
  glad you like it! it's more a book than a blog; its contents are final and immutable, so an rss feed would be of very limited interest. the sequels so far are derctuo and dernocua

anta40 3y ago

My impression so far is (in general), Forth are practically limited to doing embedded/microcontroller development. For us, web/mobile/desktop app devs, beside: - 8th (https://8th-dev.com https://8th-dev.com) - Factor (https://factorcode.org https://factorcode.org) Any suggestion which implementation we should look for?

mud_dauber 3y ago

I spent a year at Harris Semi’s RTX group. A previous gig as a Forth programmer plus undergrad work in assembly programming came in handy. I really wish RTX had caught on with commercial clients, but the lack of tools made it tough for most folks.