cforth

ned "on", causes a hand or lever to appear from inside the box that switches the machine "off" before disappearing inside the box again) appears to have been invented by MIT professor and artificial intelligence pioneer Marvin Minsky, while he was a graduate student at Bell Labs in 1952. Minsky dubbed his invention the "ultimate machine", but this nomenclature did not catch on. The device has also been called the "Leave Me Alone Box". So here's a live demo of an ultimate thing I pleasure programmed: https://hyperties.org/cabinet/ultimate/ What this is: I've been using Claude to recreationally develop a PDP-7 and Type 340 vector graphics display emulator for the web browser, in order to run an early CAD system called PIXIE, which has the first known radial menus, driven by a light pen, developed at Cambridge in the late 1960's, whose 128 pages of PDP-7 assemblxy language source code the author Heinz Lemke scanned and sent me. Once I got it working, I told Mitch Bradley about how much I wanted a Forth system for it. Mitch has written useful things like OpenFirmware and CForth, and I was his summer intern at Sun in 1987, where we had a fun time hacking his CForth into CADroid (a circuit editing system developed at LucasFilms) as an extension language and macro system. https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/cforth http://www.art.net/~hopkins/Don/lang/forth.html Since then, Mitch developed his Sun Forth system into OpenFirmware for the boot ROMs of systems like the Sparcstation, PowerPC Mac, and the OLPC. So naturally I thought it would be fun to run Forth on the same machine that ran PIXIE, mainly because I'd love to work together and hack Forth with Mitch again after all these years, but also because Forth was the perfect language for the PDP-7. So then Mitch used Claude to whip up a PDP-7 Forth in one day, with Turtle Graphics! https://github.com/MitchBradley/pdp7forth https://hyperties.org/cabinet/forth/ It turns out that the PDP-7 instruction set is ideal for Forth. It has an "XCT" instruction for indirectly executing other instructions, which makes the Forth inner interpreter loop only require 3 instructions. PDP-7 Forth — Mitch Bradley, 26 September 2026: https://github.com/SimHacker/WillWrightShowForFood/blob/main... PDP-7 Forth, by Mitch Bradley: https://github.com/SimHacker/WillWrightShowForFood/blob/main... PDP-7 Forth Source Code, NEXT: The Inner Interpreter: https://github.com/SimHacker/WillWrightShowForFood/blob/main... " --- NEXT: the inner interpreter --- " Only LAC/LAW-tag cells fall through to "dac i 012"; CAL/JMP-tag cells " transfer control elsewhere and never reach it. next: xct i 010 " pre-increment IP, execute the thread cell dac i 012 " push AC (only reached by constant/variable cells) jmp next Now that Forth runs like a bat out of hell, I'm hacking virtual hardware devices for the PDP-7, and controlling and visualizing them with Forth. First I made an "Ultimate Machine" device for the PDP-7, inspired by Claud Shannon and Marvin Minsky, whose only purpose is to turn itself off! https://en.wikipedia.org/wiki/Useless_machine Bruno Munari called it a "Useless Machine", but Minsky was more compassionate, and appreciated its purpose of turning itself off as being ultimately useful, so he renamed it the Ultimate Machine. I think there are some deep implications to the halting problem, but I can't quite put my finger on it the way the Ultimate Machine puts its finger on its own off switch. The Ultimate Machine emulator plugs into the PDP-7 emulator as a virtual device cabinet, which has its own device control IOTs that augment the PDP-7 instruction set. DEC sold a lot of "plug-in instruction sets in a cabinet" like the Type 340 vector graphics display, its light pen, character generator, subroutine executer, advanced math instructions, etc. https://gunkies.org/wiki/Type_340_Precision_Incremental_Disp... The Ultimate Machine device, an emulator of device 56 with its registers, phases and IOTs: https://github.com/SimHacker/WillWrightShowForFood/blob/main... https://github.com/SimHacker/WillWrightShowForFood/blob/main... Then I made a Forth program that draws an animation of the Ultimate Machine on the 340 display, with a switch activated by the light pen. It's not a "simulation" -- it's an actual interactive visual representation of the emulated Ultimate Machine device state that FORTH controls via IOT instructions, the same way it controls the 340 display and light pen! The Forth 340 view, with the IOT words, the hand, lid and lamps, and the light-pen switch, so you can turn it on (and off) with the light pen (check out the tool tips the emulator user interface shows you when you point at the graphics): https://github.com/SimHacker/WillWrightShowForFood/blob/main... Instead of halting there, for even more Turing completeness, I made a Turing Machine device, which is like the 340 display in that it not only adds device control IOT instructions, but also executes its own Turing Machine instructions and tape via DMA from of the same 18-bit core memory as the PDP-7 and 340 display. The 340 display and the Turing Machine are both co-processors that execute their own instructions from the shared 18-bit core memory of the PDP-7, which generates code for them to execute, and controls them via IOT instructions. The Turing Machine device issues an interrupt when its head page faults off the edge of the tape window in core, so the PDP-7 can implement virtual memory to support "infinite" tape. Live Demo: https://hyperties.org/cabinet/turing/ Turing Engine: https://github.com/SimHacker/WillWrightShowForFood/blob/main... Forth => Turing Machine Compiler I made based on Christopher Cherniak's "TM*" courseware from the "Philosophy and Computers" course I took from him in the 1980's: https://github.com/SimHacker/WillWrightShowForFood/blob/main... https://terpconnect.umd.edu/~cherniak/philcomp/ https://terpconnect.umd.edu/~cherniak/PhlCogSci.pdf Ostensibly the real use is for education, but I actually did it because it was fun, and I felt like working with Mitch and programming Forth again. Forth, the 340, and co-processors in one core: what the cabinet teaches: https://github.com/SimHacker/WillWrightShowForFood/blob/main... Here's a demo video that tries to explain it: PIXIE and FORTH on PDP-7 Cabinet Emulator with Type 340 Vector Graphics Display: https://www.youtube.com/watch?v=lo8kdY-5i6c

TC), subroutine-threaded (STC), or token-threaded (TTC), with 16, 32, or 64 bit cells. Shipping kernels are DTC native code with cell-sized xt pointers: 32 bit on the original SPARC and PowerPC machines, 64 bit on modern PPC64, SPARC64, and ARM64 builds. Peripheral expansion cards ship a separate, portable, variable-byte token format called FCode. The kernel interprets FCode at boot/probe time and recompiles it on the fly into the live native dictionary. After probe, FCode-loaded drivers run as ordinary native Forth words. That two-stage design (fast native runtime, portable FCode transport) is what let Sun ship one card PROM image that worked across CPU generations. https://github.com/MitchBradley https://github.com/MitchBradley/openfirmware FCode was designed for SBus on the SPARCstation 1, with cross-CPU portability built in. Sun's earlier and contemporary buses were not interchangeable with SBus (Sun-2 used Multibus, Sun-3 used VMEbus, the Sun386i "Roadrunner" used AT-bus), so the cross-architecture payoff arrived later, when IEEE 1275-1994 standardized OpenFirmware and PCI allowed FCode in option ROMs. After that, the same expansion-card PROM image could boot on Sun SPARC, Apple PowerPC Macs, IBM PowerPC servers (CHRP), and the OLPC XO. Interview with Mitch Bradley (he's like the Woz of Forth): https://web.archive.org/web/20120118132847/http://howsoftwar... In parallel with the OpenBoot work, Mitch also developed an extremely portable C-based Forth (the public version is "C Forth 93"). It runs a switch-threaded inner interpreter over packed tokens, with configurable cell width (16, 32, or 64 bit) and configurable token width (pointer-sized by default, 16 bit with the T16 build flag for tight flash budgets), plus a small hand-rolled FFI built around a fixed-arity 12-argument marshalling trampoline driven by a format string. It is now the embedded variant used in OLPC's OpenFirmware and in PlatformIO targets including RP2040, Teensy, ESP32, ESP8266, and STM32: https://github.com/MitchBradley/cforth OpenFirmware even has its own song: https://www.youtube.com/watch?v=b8Wyvb9GotM More on Mitch, OpenFirmware, and CForth: https://news.ycombinator.com/item?id=21822840 https://news.ycombinator.com/item?id=33681531 https://news.ycombinator.com/item?id=38689282

282 Here are the control structures in kernel.fth (this is some beautiful FORTH code to read for pleasure): kernel.fth: https://github.com/MitchBradley/openfirmware/blob/master/for... Here is the same approach in CForth, the low level C kernel code (necessarily ugly C macrology) and the higher level FORTH control structure definitions (more beautiful FORTH code): forth.c: https://github.com/MitchBradley/cforth/blob/master/src/cfort... control.fth: https://github.com/MitchBradley/cforth/blob/master/src/cfort... Here is another paper about refactoring the FORTH compiler/interpreter with deferred words that Mitch wrote called "Yet Another Interpreter Organization": https://groups.google.com/g/comp.lang.forth/c/lKQjcJL_o54/m/... >There has been a mild controversy in the Forth community about how to implement the text interpreter. The particular problem is how the distinction between compiling and interpreting should be coded. At least three distinct solutions have been advocated over the years. I propose a fourth one, and claim that it is the best solution yet. [describes FIG-FORTH's solution with STATE, PolyForth's solution with two separate loops for compiling and interpreting, Bob Berkey's coroutines approach] >What is Wrong with all this >These different schemes do not at all address what I consider to be the fundamental problems with the interpreter/compiler. >Fundamental Problem #1: >The compiler/interpreter has a built-in infinite loop. This means that you can't tell it to just compile one word; once you start it, off it goes, and it won't stop until it gets to the end of the line or screen. >Fundamental Problem #2: >The reading of the next word from the input stream is buried inside this loop. This means that you can't hand a string representing a word to the interpreter/compiler and have it interpret or compile it for you. >Fundamental Problem #3: >The behavior of the interpreter/compiler is hard to change because all the behavior is hard-wired into one or two relatively large words. Changing this behavior can be extremely useful for a number of applications, for example meta-compiling. >Fundamental Problem #4: >If the interpreter/compiler can't figure out what to do with a word (it's not defined and it's not a number), it aborts. Worse yet, the aborting is not done directly from within the loop, but inside NUMBER. This severly limits the usefulness of NUMBER because if the string that NUMBER gets is not recognizable as a number, it will abort on you. (The 83 standard punts this issue by not specifying NUMBER, except as an uncontrolled reference word). [describes Mitch's solution of making DO-DEFINED, DO-LITERAL, and DO-UNDEFINED a deferred word] >So what? >This may seem to be more complicated than the schemes it replaces. It certainly does have more words. On the other hand, each word is individually easy to understand, and each word does a very specific job, in contrast to the old style, which bundles up a lot of different things in one big word. The more explicit factoring gives you a great deal of control over the interpreter. [describes cool examples of what you can do with it] >Finally, a really neat way to write keyword-driven translators. Suppose you have some kind of a file that contains a bunch of text. Interspersed throughout the text are keywords that you would like to recognize, and the program should do something special when it sees a keyword. For things that aren't keywords, it just writes them out unchanged. Suppose that the keywords are ".PARAGRAPH", ".SECTION", and ".END". [...] >I have used this technique very successfully to extract specific information from data base files produced by a CAD system. Instead of outputting unrecognized words, I actually just ignored them in this application, but the technique is the same in either case. Mitch Bradley Bradley Forthware P.O. Box 4444 Mountain View, CA 94040 wmb@forthware.com Mitch had the coolest P.O. Box address for his Forthware company in Mountain View! This deferred word approach is actually what I used for the HyperTIES markup language interpreter/formatter for NeWS I wrote in Forth and C and PostScript, using Mitch's Sun Forth / Forthmacs (predecessor to OpenFirmware that ran on the Sun): https://donhopkins.com/home/ties/doc/formatter.st0 https://donhopkins.com/home/ties/fmt.f https://donhopkins.com/home/ties/fmt.c https://donhopkins.com/home/ties/fmt.cps https://donhopkins.com/home/ties/fmt.ps

hen 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=38689282 Mitch Bradley came up with a nice way to refactor the Forth compiler/interpreter and control structures, so that you could use them immediately at top level! Traditional FORTHs only let you use IF, DO, WHILE, etc in : definitions, but they work fine at top level in Mitch's Forths (including CForth and Open Firmware). [...] https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/cforth

ingforum.com/t/apples-purple-cray-hooked-... UniPress ported and sold a commercial version of the "Extended Amsterdam Compiler Kit" for Andrew Tanenbaum for many CPUs and versions of Unix (like they also ported and sold his Unix version of Emacs for James Gosling), so Emacs might have been compiled with ACK on the Cray, but I don't recall. During the late 80's and early 90's, UniPress's Enhanced ACK cost $9,995 for a full source license, $995 for an educational source license, with front ends for C, Pascal, BASIC, Modula-2, Occam, and Fortran, and backends for VAX, 68020, NS32000, Sparc, 80368, and others, on many contemporary versions of Unix. Rehmi Post at UniPress also made a back-end for ACK that compiled C to PostScript for the NeWS window system and PostScript printers, called "c2ps", which cost $2,995 for binaries or $14,995 for sources. Independently Arthur van Hoff wrote a different C to PostScript compiler called "PdB" at the Turing Institute, not related to c2ps. It was a much simpler, more powerful, more direct compiler written from scratch, and it supported object oriented PostScript programming in NeWS, subclassing PostScript from C or C from PostScript. I can't remember how much Turing sold it for, but I think it was less than c2ps. https://compilers.iecc.com/comparch/article/92-04-041 http://www.aaronjamesrogers.com/misc/hotmix16/vendors/sgi/ap... https://donhopkins.com/home/archive/NeWS/NeScheme.txt https://news.ycombinator.com/item?id=10088193 I got to watch Apple's Cray compile Emacs very quickly through the plexiglass viewing window, but they wouldn't let me sit or nap on it, alas. I knew a guy who worked at one of the national labs that had its own Cray supercomputer, in a computer room with a big observation window that visitors could admire it through, of course (all Crays required observations windows to show them off). Just before a tour group came by, he hid inside the Cray, and waited for them to arrive. Then he casually strolled out from the back of the Cray, pulling up the zipper of his jeans, with a sheepish relieved expression on his face, looked up and saw the tour group, acted startled, then scurried away.

I got a quick reply from Mitch Bradley! Yes I wrote a paper but I probably can't find it. The easiest place to look would be in the Open Firmware source. https://github.com/MitchBradley/openfirmware/blob/master/for... The magic is all in +level and -level. Search for those in kernel.fth to see other places they are used to achieve a similar effect, e.g. in abort" For an alternative but effectively equivalent formulation, see: https://github.com/MitchBradley/cforth/blob/master/src/cfort... and https://github.com/MitchBradley/cforth/blob/master/src/cfort... [...] https://news.ycombinator.com/item?id=29264309 In PostScript that would be: /PostScript Know? { Honk! } { /PostScript Learn! } ifelse FORTH doesn't have an IFELSE unless you define it yourself of course, but it would have no way of telling which part of your code was the conditional, part to do if true, or part to do if false, since white space and line breaks have no meaning to it, except for a few cases like \ comments. The IF comes between the conditional and the part to do if true, the ELSE comes between the part to do if true and the part to do if false, and the THEN comes at the end. The structure of PostScript code, conditionals, and flow control is homoiconic, made of nested arrays, like polymorphic JSON arrays, where FORTH code is flat untyped arrays of threaded pointers with relative branching. Forth has an "inner interpreter" called NEXT that threads from one pointer to the next (sometimes implemented as one machine language instruction, or just a few), and also an "outer interpreter" or compiler that translates text into threaded code for the inner interpreter. https://en.wikipedia.org/wiki/Polymorphism_(computer_science... https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Threaded_code Here's Mitch Bradley's implementation of interactive control structures (IF, ELSE, THEN, BEGIN, UNTIL, AGAIN, REPEAT, WHILE, DO, LOOP, etc) in the outer interpreter of his FORTH system, which actually allows you to use conditionals and loops at the interactive top level of the interpreter, not just in compiled words (which solves a traditional and frustrating limitation of classic FORTH). https://github.com/MitchBradley/openfirmware/blob/master/for... Here is an alternative but equivalent implementation of interactive Forth control structures in his CForth (Forth implemented in C, of course): https://github.com/MitchBradley/cforth/blob/master/src/cfort... Here's some more of Mitch's beautiful code from OpenFirmware, his Forth kernel meta-compiler written in Forth, which supports 8, 16, 32, an 64 bit, big-endian and little-endian architectures, as well as direct, indirect, and token threaded code: https://github.com/MitchBradley/openfirmware/blob/master/for... https://en.wikipedia.org/wiki/Threaded_code#Direct_threading https://en.wikipedia.org/wiki/Threaded_code#Indirect_threadi... https://en.wikipedia.org/wiki/Threaded_code#Token_threading [...] https://news.ycombinator.com/item?id=29265144 Some FORTH systems even have a "metacompiler" that lets one FORTH system compile another FORTH system for the same or different CPU, word size, byte order, threading technique, with or without a built-in compiler, etc, from the same source code! OpenFirmware (the FORTH burnt into boot roms of SPARC, PowerPC, OLPC, and other systems) is a great highly refined example that supports many different architectures: openfirmware/forth/kernel/metacompile.fth https://github.com/openbios/openfirmware/blob/master/forth/k... openfirmware/forth/kernel/meta1.fth https://github.com/openbios/openfirmware/blob/master/forth/k... The OpenFirmware kernel is a Forth meta-compiler, which can compile itself on any architecture, and also cross-compile for different target architectures. It has cross-architecture extensions to FORTH (like \16 \32 comments and /n /n* generically typed words) that make it possible to write platform, word size, byte order, and threading independent code, and compile images (stripped or with headers) for embedded systems (like the OLPC boot ROMs) and new CPU architectures (like Sun's transition from 68K to SPARC), and share code with a more powerful development environments. https://en.wikipedia.org/wiki/Compiler-compiler#Forth_metaco... [...] https://news.ycombinator.com/item?id=29264489 [...] Here's some IBM-PC Forth for the CAM-6 cellular automata machine that was block based -- check out the unique idiosyncratic right-justified reverse-indentation style (starting with KGET), which is not standard Forth style, but sure looks cool and poetic, like E E CUMMINGS ON CAPS LOCK: https://donhopkins.com/home/code/tomt-cam-forth-scr.txt https://donhopkins.com/home/code/tomt-users-forth-scr.txt [...] https://news.ycombinator.com/item?id=29261868 Coco Conn and Paul Rother wrote this up about what they did with FORTH at HOMER & Assoc, who made some really classic music videos including Atomic Dog, and hired Charles Moore himself! Here's what Coco Conn posted about it, and some discussion and links about it that I'm including with her permission: [...] Forth & Charles Moore We hired Forth, Inc. and got Charles Moore, the inventor of FORTH to program the console host computer. I learned FORTH and worked with Charles. I programmed the 2K byte EPROM in each visual channel. On the Master Z80 system we ran PolyForth a multi tasking system in 32K bytes. We had an extra 16K RAM for buffers and things. If I remember right, the system ran four tasks, but that was 20 years ago, my memory may be hazy. Anyway, I learn not only FORTH from Charles Moore, but also how to factor code in to small reusable routines, WORDs they're called in FORTH. I learned Object Oriented Programming without knowing it. Also a lot of use of vectors. Its a cool language. Charles Moore was a great inspiration to me, and really taught me a great deal that they never taught me in computer programming school. [...]

rmware, portable device drivers, hardware and driver configuration, and many hardware platforms. 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 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/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://news.ycombinator.com/item?id=27484426 DonHopkins on June 12, 2021 | root | parent | next [–] From 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/cor... [...] 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://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 [...]

d versions: https://github.com/openbios https://github.com/openbios/openbios https://github.com/openbios/openfirmware https://github.com/openbios/openboot https://github.com/openbios/smartfirmware https://openfirmware.info/Welcome_to_OpenBIOS https://openfirmware.info/Open_Firmware https://github.com/MitchBradley/openfirmware Also there's also Mitch's very portable "cforth": https://github.com/MitchBradley/cforth There's even an Open Firmware Song: https://www.youtube.com/watch?v=b8Wyvb9GotM

fort... At the other end of the spectrum, there's the Novix Forth Engine! https://news.ycombinator.com/item?id=8860786 >DonHopkins on Jan 9, 2015 | parent | context | favorite | on: Design of Lisp-Based Processors Or, LAMBDA: The Ul... >The Novix FORTH chip was a pretty cool implementation of FORTH in hardware -- it had separate data and return stacks, which it could push or pop at the same time, so the compiler could combine several FORTH words into one opcode. http://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.htm... >The Novix NC4016, formerly called the NC4000, is a 16-bit stack based microprocessor designed to execute primitives of the Forth programming language. It was the first single-chip Forth computer to be built, and originated many of the features found on subsequent designs. Intended applications are real time control and high speed execution of the Forth language for general purpose programming. >The NC4016 uses dedicated off-chip stack memories for the Data Stack and the Return Stack. Since three separate groups of pins connect the two stacks and the RAM data bus to the NC4016, it can execute most instructions in a single clock cycle. https://web.archive.org/web/20160402032358/http://www.forth.... >The NC4000P is a single chip FORTH Engine based upon minimum hardware concepts developed by Mr. Charles H. Moore. This highly parallel machine architecture directly executes FORTH primitives in a single clock cycle. The initial implementation of this device is based upon a 4000 gate CMOS semicustom integrated circuit operating at an 8 MHz clock rate. But I'm preaching to the choir, Jacques! ;) Dadadatablblblblbl! https://news.ycombinator.com/item?id=3814155 >jacquesm on April 8, 2012 | parent | context | favorite | on: A Forth Story... >Quite a story, and it seems it does not have a happy ending, but for all the wrong reasons. About 2/3rds in (past the 'read more') the Novix rates a mention. I think that that is possibly the most underrated CPU design that ever saw the light of day, at the time it was so out of the ordinary that only very few people knew what to do with it. >A high level language (forth is by most definitions a high level language) directly executed by the CPU. >At the time I worked for a company called dadadata in the Netherlands, they were in the process of developing a bunch of real time software to process video images for classification and recognition (1988 or thereabouts). The Novix chip arrived and would have definitely blown the socks of anything that I could have done with a regular PC at the time, if not for one small problem: someone dropped a dime into the power supply and the whole development kit was toast. A couple of all nighters later we had a working reproduction of the code in 'C' and that was used for the customer demonstrations. Still, the power of that little chip is something I'll never forget and it is a pity that the Novix and its successor which iirc was called shboom never made real headway. The forth code for the novix was probably only about 10% or so in size of the equivalent C code. The head forth honcho there called C sneeringly a 'great' language. >There is still hope, even today that one day that power will finally be available in some package that sees wide distribution, the heritage of Novix lives on in the greenarrays line (which is now shipping dev boards and chips). http://www.greenarraychips.com/ >To kill forth and the concepts behind it permanently will take a lot of garlic and stakes, I think it will always have its champions.

next (sometimes implemented as one machine language instruction, or just a few), and also an "outer interpreter" or compiler that translates text into threaded code for the inner interpreter. https://en.wikipedia.org/wiki/Polymorphism_(computer_science... https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Threaded_code Here's Mitch Bradley's implementation of interactive control structures (IF, ELSE, THEN, BEGIN, UNTIL, AGAIN, REPEAT, WHILE, DO, LOOP, etc) in the outer interpreter of his FORTH system, which actually allows you to use conditionals and loops at the interactive top level of the interpreter, not just in compiled words (which solves a traditional and frustrating limitation of classic FORTH). https://github.com/MitchBradley/openfirmware/blob/master/for... Here is an alternative but equivalent implementation of interactive Forth control structures in his CForth (Forth implemented in C, of course): https://github.com/MitchBradley/cforth/blob/master/src/cfort... Here's some more of Mitch's beautiful code from OpenFirmware, his Forth kernel meta-compiler written in Forth, which supports 8, 16, 32, an 64 bit, big-endian and little-endian architectures, as well as direct, indirect, and token threaded code: https://github.com/MitchBradley/openfirmware/blob/master/for... https://en.wikipedia.org/wiki/Threaded_code#Direct_threading https://en.wikipedia.org/wiki/Threaded_code#Indirect_threadi... https://en.wikipedia.org/wiki/Threaded_code#Token_threading

have a good decompiler / dissassembler ("SEE") like ForthMacs, CForth, and OpenFirmware do. https://news.ycombinator.com/item?id=9271644 >DonHopkins on Mar 26, 2015 | parent | favorite | on: The Elusive Universal Web Bytecode >The other "universal bytecode" that came out of Sun and actually has seen a lot of use is Mitch Bradley's Open Firmware Forth based boot ROMs, used by Suns' 68k, SPARC and x86 boxes, Apple's PPC Macs, IBM, ARM, OLCP XO-1, and many other systems. >http://en.wikipedia.org/wiki/Open_Firmware https://news.ycombinator.com/item?id=12240478 DonHopkins on Aug 7, 2016 | parent | favorite | on: “EFI? Intel has been trying to shove that down ou... >Mitch Bradley originally developed a Forth system at Sun for use diagnosing and developing hardware, by burning it into ROM and running it via a serial port. >It was based on Langston and Perry's Forth-83, and had a meta compiler that could target different word sizes and architectures. He made it even more architecture and word size independent, implemented interactive top level loops and conditionals, emacs-like line editing, all kinds of low level device drivers and testers that ran in stand-alone mode, and many other features, including full 16 and 32 bit support with a vocabulary for writing word size and endian independent code. >He ported Sun Forth to 68K and SPARC Sun workstations, as well as the Amiga and other systems. It ran in both stand-alone mode (from disk, tftp or ROM), or under Unix. Under Unix, it could dynamically relocate and link in Unix libraries, and you could call back and forth between Forth and C. >Sun Forth eventually evolved and standardized into the Open Firmware [1], whose purpose was to support machine independent byte code [2], so plug-in hardware cards could include ROMs with Forth byte code drivers that ran on 68K, SPARC, x86 and other systems. >Sun shipped it with the SPARC workstations, Apple adopted it and shipped it on their PowerPC Macs, IBM shipped with their POWER servers, and Mitch worked directly with the OLPC project extending OpenFirmware to support the OLPC XO-1 Children's Computer secure and power efficient hardware. [3] >>OLPC Wiki: Open Firmware >>Open Firmware is the hardware-independent firmware (computer software which loads the operating system) that the XO runs. >>It was developed by Mitch Bradley at Sun Microsystems, and used in post-NuBus PowerPC-based Apple Macintosh computers (though it has been dropped with Apple's transition to Intel processors), Sun Microsystems SPARC based workstations and servers, IBM POWER systems, and PegasosPPC systems, among others. On those computers, Open Firmware fulfills the same tasks as BIOS does on PC computers. >>For example Fedora and Debian use the YaBoot BootLoader for Open Firmware. >>The Open Firmware user interface includes a FORTH-based shell interface. FORTH is a powerful high level language that is remarkably compact. A complete Forth development environment including compiler, decompiler, assembler, disassembler, source level debugger, and assembly language debugger is present in the XO boot ROM (SPI FLASH). With the Open Firmware Forth system, you can directly access all of the hardware devices on the XO, use built-in functions like selftest diagnostics and games, and even write complete applications, without needing any external tools. The bulk of Open Firmware is written in Forth, so the source level debugger can be used to debug Open Firmware itself. >[1] http://www.openfirmware.info >[2] http://www.openfirmware.info/FCODE_suite >[3] http://wiki.laptop.org/go/Open_Firmware https://news.ycombinator.com/item?id=15040859 >DonHopkins on Aug 17, 2017 [-] >Emacs qualifies as a window manager in my book! ;) >That code you linked to is from Mitch Bradley's "Forthmacs", which ran on Sun workstations including 68k i86 and SPARC, and also Atari ST, Mac and other systems. He developed it into the "Open Boot ROM" architecture, which was used in Sun workstations and Apple PowerPC Macs as well as the OLPC children's laptop. >https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs >https://en.wikipedia.org/wiki/Open_Firmware >http://wiki.laptop.org/go/Open_Firmware >On SunOS, Forthmacs had a library clink.f with the ability to dynamically relocate and link Unix libraries so that you could call them from Forthmacs, pass arguments on the stack, etc. SunOS didn't actually support shared libraries or dynamic address relocating at that time, so Forthmacs simply ran the Unix linker utility to create a file with the library relocated to the desired address space in the FORTH dictionary, and then read that file into memory, define its symbols in the FORTH dictionary, and let you access its variables and call its functions directly from FORTH! >That's how Mitch originally integrated MicroEmacs with Forth to make Forthmacs, and how I later integrated "uwm" into FORTH: I refactored uwm so instead of having an event loop in the main function, it was a library that could be called by FORTH, which would link the library in and run the main loop itself, calling into the library as needed to initialize and handle specific events (_uwm_init, _uwm_poop). http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-mai... >Here's the glue that links in the uwm library from fuwm.out: http://www.donhopkins.com/home/archive/piemenu/uwm1/load-fuw... .( Loading...) cr requires tasking.f requires uwm.f requires clink.f .( Linking...) cr "" fuwm.out clink .( Linked!) cr https://news.ycombinator.com/item?id=17480298 >DonHopkins on July 7, 2018 | parent | favorite | on: Tali Forth 2 for the 6502 >Cool! Does it include a FORTH 6502 assembler written in FORTH? I love writing assembly code in RPN with Forth macros! >You can write FORTH code with loops and conditionals and any kind of logic and parameters, that dynamically assembles machine code! Much better than your typical macro assembler. >Here's some 6502 assembler for an Apple ][ SUPDUP terminal emulator that does ram card bank switching: >http://www.donhopkins.com/home/archive/forth/supdup.f >Here's some Forth 68k assembler that draws lines on a weird Sun-2 CGONE graphics board. >http://www.donhopkins.com/home/archive/forth/cg/bline.f >Mitch Bradley's 68k forth lets you use interactive conditionals and loops in the top level outer interpreter! >I think he wrote a paper about that feature, which I might be able to dig up ... Here's something related he wrote about refactoring the outer interpreter, but not what I'm thinking of: https://groups.google.com/forum/#!topic/comp.lang.forth/lKQj... >avhon1 on July 7, 2018 [-] >> Does it include a FORTH 6502 assembler written in FORTH? https://github.com/scotws/TaliForth2/blob/master/docs/manual... >>Currently, there is no assembler included. The plan is to include a simple assembler based on Simpler Assembler Notation (SAN). >It does include a disassembler: https://github.com/scotws/TaliForth2/blob/master/docs/ch_dis... >The author has written a 6502 assembler in gforth: https://github.com/scotws/tasm65c02 >Here is a document describing the notation: https://docs.google.com/document/d/16Sv3Y-3rHPXyxT1J3zLBVq4r... >DonHopkins on July 7, 2018 [-] >I got a quick reply from Mitch Bradley! >Yes I wrote a paper but I probably can't find it. The easiest place to look would be in the Open Firmware source. >https://github.com/MitchBradley/openfirmware/blob/master/for... >The magic is all in +level and -level. Search for those in kernel.fth to see other places they are used to achieve a similar effect, e.g. in abort" >For an alternative but effectively equivalent formulation, see: >https://github.com/MitchBradley/cforth/blob/master/src/cfort... >and >https://github.com/MitchBradley/cforth/blob/master/src/cfort... lukego on Dec 18, 2019 [–] I love your posts about this stuff :) I was also an "intern" of sorts for Mitch as recently as 2009 or so. I wrote the audio driver for OLPC XO 1.5 and went to Taipei to help with the bringup. I was amazed to watch Mitch using Forth to interactively tweak the DDR memory settings, find bugs in the motherboard, and find bugs in the CPU which was a godawful x86 from VIA that had seemingly only been debugged enough to boot windows :) DonHopkins on Dec 18, 2019 | parent [–] That must have been a fun and unique opportunity! His programming and debugging process has to be seen to be believed. OpenFirmware is definitely a highly polished work of love. Its well-commented and meticulously organized source code reads like fine literature or classical music! Stuff like the metacompiler and kernel, for example: https://github.com/MitchBradley/openfirmware/blob/master/for... https://github.com/MitchBradley/openfirmware/blob/master/for...

m?id=9271644 >DonHopkins on Mar 26, 2015 | parent | favorite | on: The Elusive Universal Web Bytecode >The other "universal bytecode" that came out of Sun and actually has seen a lot of use is Mitch Bradley's Open Firmware Forth based boot ROMs, used by Suns' 68k, SPARC and x86 boxes, Apple's PPC Macs, IBM, ARM, OLCP XO-1, and many other systems. >http://en.wikipedia.org/wiki/Open_Firmware https://news.ycombinator.com/item?id=12240478 DonHopkins on Aug 7, 2016 | parent | favorite | on: “EFI? Intel has been trying to shove that down ou... >Mitch Bradley originally developed a Forth system at Sun for use diagnosing and developing hardware, by burning it into ROM and running it via a serial port. >It was based on Langston and Perry's Forth-83, and had a meta compiler that could target different word sizes and architectures. He made it even more architecture and word size independent, implemented interactive top level loops and conditionals, emacs-like line editing, all kinds of low level device drivers and testers that ran in stand-alone mode, and many other features, including full 16 and 32 bit support with a vocabulary for writing word size and endian independent code. >He ported Sun Forth to 68K and SPARC Sun workstations, as well as the Amiga and other systems. It ran in both stand-alone mode (from disk, tftp or ROM), or under Unix. Under Unix, it could dynamically relocate and link in Unix libraries, and you could call back and forth between Forth and C. >Sun Forth eventually evolved and standardized into the Open Firmware [1], whose purpose was to support machine independent byte code [2], so plug-in hardware cards could include ROMs with Forth byte code drivers that ran on 68K, SPARC, x86 and other systems. >Sun shipped it with the SPARC workstations, Apple adopted it and shipped it on their PowerPC Macs, IBM shipped with their POWER servers, and Mitch worked directly with the OLPC project extending OpenFirmware to support the OLPC XO-1 Children's Computer secure and power efficient hardware. [3] >>OLPC Wiki: Open Firmware >>Open Firmware is the hardware-independent firmware (computer software which loads the operating system) that the XO runs. >>It was developed by Mitch Bradley at Sun Microsystems, and used in post-NuBus PowerPC-based Apple Macintosh computers (though it has been dropped with Apple's transition to Intel processors), Sun Microsystems SPARC based workstations and servers, IBM POWER systems, and PegasosPPC systems, among others. On those computers, Open Firmware fulfills the same tasks as BIOS does on PC computers. >>For example Fedora and Debian use the YaBoot BootLoader for Open Firmware. >>The Open Firmware user interface includes a FORTH-based shell interface. FORTH is a powerful high level language that is remarkably compact. A complete Forth development environment including compiler, decompiler, assembler, disassembler, source level debugger, and assembly language debugger is present in the XO boot ROM (SPI FLASH). With the Open Firmware Forth system, you can directly access all of the hardware devices on the XO, use built-in functions like selftest diagnostics and games, and even write complete applications, without needing any external tools. The bulk of Open Firmware is written in Forth, so the source level debugger can be used to debug Open Firmware itself. >[1] http://www.openfirmware.info >[2] http://www.openfirmware.info/FCODE_suite >[3] http://wiki.laptop.org/go/Open_Firmware https://news.ycombinator.com/item?id=15040859 >DonHopkins on Aug 17, 2017 [-] >Emacs qualifies as a window manager in my book! ;) >That code you linked to is from Mitch Bradley's "Forthmacs", which ran on Sun workstations including 68k i86 and SPARC, and also Atari ST, Mac and other systems. He developed it into the "Open Boot ROM" architecture, which was used in Sun workstations and Apple PowerPC Macs as well as the OLPC children's laptop. >https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs >https://en.wikipedia.org/wiki/Open_Firmware >http://wiki.laptop.org/go/Open_Firmware >On SunOS, Forthmacs had a library clink.f with the ability to dynamically relocate and link Unix libraries so that you could call them from Forthmacs, pass arguments on the stack, etc. SunOS didn't actually support shared libraries or dynamic address relocating at that time, so Forthmacs simply ran the Unix linker utility to create a file with the library relocated to the desired address space in the FORTH dictionary, and then read that file into memory, define its symbols in the FORTH dictionary, and let you access its variables and call its functions directly from FORTH! >That's how Mitch originally integrated MicroEmacs with Forth to make Forthmacs, and how I later integrated "uwm" into FORTH: I refactored uwm so instead of having an event loop in the main function, it was a library that could be called by FORTH, which would link the library in and run the main loop itself, calling into the library as needed to initialize and handle specific events (_uwm_init, _uwm_poop). >http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-mai... >Here's the glue that links in the uwm library from fuwm.out: >http://www.donhopkins.com/home/archive/piemenu/uwm1/load-fuw... .( Loading...) cr requires tasking.f requires uwm.f requires clink.f .( Linking...) cr "" fuwm.out clink .( Linked!) cr https://news.ycombinator.com/item?id=17480298 >DonHopkins on July 7, 2018 | parent | favorite | on: Tali Forth 2 for the 6502 >Cool! Does it include a FORTH 6502 assembler written in FORTH? I love writing assembly code in RPN with Forth macros! >You can write FORTH code with loops and conditionals and any kind of logic and parameters, that dynamically assembles machine code! Much better than your typical macro assembler. >Here's some 6502 assembler for an Apple ][ SUPDUP terminal emulator that does ram card bank switching: >http://www.donhopkins.com/home/archive/forth/supdup.f >Here's some Forth 68k assembler that draws lines on a weird Sun-2 CGONE graphics board. >http://www.donhopkins.com/home/archive/forth/cg/bline.f >Mitch Bradley's 68k forth lets you use interactive conditionals and loops in the top level outer interpreter! >I think he wrote a paper about that feature, which I might be able to dig up ... Here's something related he wrote about refactoring the outer interpreter, but not what I'm thinking of: >https://groups.google.com/forum/#!topic/comp.lang.forth/lKQj... >avhon1 on July 7, 2018 [-] >> Does it include a FORTH 6502 assembler written in FORTH? >https://github.com/scotws/TaliForth2/blob/master/docs/manual... >>Currently, there is no assembler included. The plan is to include a simple assembler based on Simpler Assembler Notation (SAN). >It does include a disassembler: https://github.com/scotws/TaliForth2/blob/master/docs/ch_dis.... >The author has written a 6502 assembler in gforth: https://github.com/scotws/tasm65c02 >Here is a document describing the notation: https://docs.google.com/document/d/16Sv3Y-3rHPXyxT1J3zLBVq4r... >DonHopkins on July 7, 2018 [-] >I got a quick reply from Mitch Bradley! >Yes I wrote a paper but I probably can't find it. The easiest place to look would be in the Open Firmware source. >https://github.com/MitchBradley/openfirmware/blob/master/for... >The magic is all in +level and -level. Search for those in kernel.fth to see other places they are used to achieve a similar effect, e.g. in abort" >For an alternative but effectively equivalent formulation, see: >https://github.com/MitchBradley/cforth/blob/master/src/cfort... >and >https://github.com/MitchBradley/cforth/blob/master/src/cfort...