cforth

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...

to by IP 0129 024A 88 DEY 0130 024B B1 AE LDA (IP),Y 0131 024D 85 B1 STA W 0132 024F 20 6F 02 JSR TRACE Remove this when all is well 0133 0252 18 CLC Increment IP by two 0134 0253 A5 AE LDA IP 0135 0255 69 02 ADC #2 0136 0257 85 AE STA IP 0137 0259 90 02 BCC L54 0138 025B E6 AF INC IP+1 0139 025D 4C B0 00 L54 JMP W-1 Jump to an indirect jump (W) (This is actually self-modifying code that write the indirect address to jump to into W, the operand of an indirect JMP instruction at W-1, then does an absolute JMP to W-1 to jump indirect through W.) Some CPUs can implement "NEXT" in one or only a few instructions, and FORTH implementations can use "indirect threading" (like the above 6502 implementation that indirectly jumps through each word's CFA (Code Field Address)) or "direct threading" where the word pointers refer directly to code, or they can even compile words directly to machine language instructions instead of threaded pointers (so there's effectively no inner interpreter, just direct machine language calls), and in that case they can even inline "NEXT" at the end of every word definition for speed, instead of jumping to a global "NEXT" implementation (subroutine threaded machine code). https://en.wikipedia.org/wiki/Threaded_code#Threading_models And there are other possible variations and hybrid combinations, like "subroutine threading" or "token threading", which you might want to use to implement FORTH systems in C or other higher level languages, using function pointers (like CForth) or switch statement tokens for built-in primitives (like machine-independent OpenFirmware byte code): https://github.com/MitchBradley/cforth https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Dir... The outer interpreter is the parser and compiler, which is written in FORTH, and includes a bunch of words, but is extremely simple (and extremely extensible) compared to other language interpreters. The outer interpreter can be in interpret or compile mode (controlled by a variable called "STATE"): when you're typing expressions interactively in interpret state, it executes them immediately, but when you start a word definition (with ":") it goes into compile state and compiles the words instead of executing them. Except that in compile mode it does execute specially marked "immediate" words, with which you can implement control flow and macros. There are immediate words [ and ] that switch between compile/interpret states, so in the middle of a word definition you can pop out into interpret mode and execute arbitrary computations (like macros or meta programming), then pop back into compile mode. For example you could compute a number, and then compile it as an inline literal! And then there's <builds and does>, which are word defining words, that let you do certain kinds of meta-programming, implement your own domain specific languages, data types, object systems, and extend the FORTH interpreter and compiler in FORTH. http://www.forth.org/svfig/Len/definwds.htm >It has been said that one does not write a program in Forth. Rather, one extends Forth to make a new language specifically designed for the application at hand. An important part of this process is the defining word, by which it is possible to combine a data structure with an action to create multiple instances that differ only in detail. One thinks of a cookie-cutter; all the cookies are the same shape but have different-colored icing.