Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Forth Programming

call-with-current-continuation.org

Post reply on HN
Print view View original

41–50 of 97 posts

Re: Thoughts on Forth Programming

#41

Post by DonHopkins »

lukego wrote: post #36
markus_zhang wrote: post #13

Can you please give some examples on those who are extremely productive using FORTH? I'm intrigued. I think FORTH could be very useful to someone who prefers to work alone or in small group, but I'm not sure how do they use it in daily life.

Mitch Bradley. He wrote the firmware for Sun machines, made an IEEE standard of it, open sourced it for OLPC. Highly productive guy. Interview with him seems to have disappeared from the web? http://mitchbradley.blogspot.com/2010/08/open-firmware-and-o...

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

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

Re: Thoughts on Forth Programming

#42

Post by jacquesm »

stewbrew wrote: post #35
nvahalik wrote: post #2

> In Forth there is only memory - word and byte-sized cells of storage in memory, and stacks. You step down on the level of assembly language which may sound daunting, yet gives you full control over every aspect of memory layout. Other than in niche or pet projects, can this even work? If you deal with any sort of multibyte data like Unicode, doesn’t this become way harder? Or do you just punt and use ascii code pag…

On a new OS, forth often has a "first mover" advantage. E.g. some of the first apps for MacOS were developed in forth. It's also useful when limited resources are available. OO forth is quite pleasant to work in, if you really want to. That said, I wish somebody would have created a statically typed forth.

http://kittenlang.org/

Re: Thoughts on Forth Programming

#43

Post by jacquesm »

LessDmesg wrote: post #9
nvahalik wrote: post #2

> In Forth there is only memory - word and byte-sized cells of storage in memory, and stacks. You step down on the level of assembly language which may sound daunting, yet gives you full control over every aspect of memory layout. Other than in niche or pet projects, can this even work? If you deal with any sort of multibyte data like Unicode, doesn’t this become way harder? Or do you just punt and use ascii code pag…

This can work, but it's incredibly tedious and not worth the trouble. Writing in Forth is like writing in pure CIL or JVM bytecode (they're both stack machines like Forth). Sure, you can do it, but if it was so rewarding, people wouldn't be using Java or C#.

At a guess you've never actually done any significant programming in Forth.

The 777 wouldn't fly if you took out all the Forth code and there are plenty of other examples. Forth is at a much higher level than JVM byte code, byte code would be comparable to the output of a Forth compiler in roughly the same way that a .S file could be the output of a C compiler. Clearly C is at a (somewhat) higher level than Assembly.

Forth is definitely an acquired taste, but it is an interesting shift in perspective and as such a language that is worth learning, not because it will have a lot of commercial potential but because it makes you look at problems in a different way.

The same goes for LISP, Erlang/Elixir and Clojure.

Re: Thoughts on Forth Programming

#44

Post by jacquesm »

kabdib wrote: post #29
kick wrote: post #10

Earlier quoted context omitted.

That's not true at all. I know multiple people who are incredibly productive in Forth environments, though I don't use it myself. Pretending that it's like writing in JVM bytecode (despite some overlap between the two) is completely unfounded. Your claim that C# and Java won based on merits is similarly unfounded: they won because they have major corporate backing. There are countless languages before and after that…

I've met a couple of really good FORTH programmers over the years. They were humble about it, were also happy to use other tools in their work, and they just happened to be working on projects that were really good fits for FORTH's strengths. I've met a lot more FORTH fanatics, people for whom FORTH was the answer no matter the problem; people who just would not shut up about how superior and fantastic it was, and ha…

> I've met a lot more FORTH fanatics, people for whom FORTH was the answer no matter the problem; people who just would not shut up about how superior and fantastic it was, and have you seen the light, brother?

I've seen exactly one Forth programmer like that, they are simply too rare. But the stereotype language fanatic is easily recognized in other language eco-systems, Perl and Rust have a disproportionately high share of this and I'm sure there are others. Typically this stems from either insecurity or a lack of exposure to other eco-systems or the drive to create camps of in and out groups to attempt to gain mindshare.

Very tiring and counterproductive in the long run, I think to some extent this is what killed Perl, simply that no matter how good the language was/is regular people simply don't want to be associated with fanatics and recognize that no tool will ever be perfect.

Re: Thoughts on Forth Programming

#45

Post by lukego »

DonHopkins wrote: post #41
lukego wrote: post #36

Earlier quoted context omitted.

Mitch Bradley. He wrote the firmware for Sun machines, made an IEEE standard of it, open sourced it for OLPC. Highly productive guy. Interview with him seems to have disappeared from the web? http://mitchbradley.blogspot.com/2010/08/open-firmware-and-o...

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 memori…

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 :)

Re: Thoughts on Forth Programming

#46

Post by jacquesm »

LessDmesg wrote: post #39
lebuffon wrote: post #12

Earlier quoted context omitted.

It's not like pure CIL or JVM bytecode when the language can be extended. The process is to make what you need and only then write the program. It's remarkable how fast you can move up language levels once you grok it.

This is hard to believe, as in this thread and everywhere, the only software used to tout Forth is low-level stuff. Even if Forth was able to be squeezed into a high-level language, it doesn't seem to have any advantage, or, in fact any differences from existing ones. What would a high-level Forth bring to the table that Java or e.g. Clojure don't have?

Because Forth isn't really an application development language as much as it is a very flexible toolbox for programmers who are toolmakers themselves. You can write full applications in it but that is not where Forth shines. If I had to bring up a new machine though that would be one of the first things I would port. (And it would take a couple of hours at most once the hardware was up and running)

Re: Thoughts on Forth Programming

#47

Post by tom_mellior »

rabidrat wrote: post #31
jancsika wrote: post #21

> One such property is the use of reverse polish notation and the lack or eschewal of local variables. What do you gain by eschewing local variables in favor of reverse polish notation that throws values onto a stack?

There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. Eschewing local variables means you have fewer things to name.

I never understood the "naming things" part to be about temporary variables. IMO it's about exported APIs, global identifiers, and especially about finding resources by some useful name in a distributed system.

In any case, Forth is a language for implementing your own DSLs by defining a whole bunch of "words" that all need to be named. So it's not like you get around the harder part of "naming things".

Re: Thoughts on Forth Programming

#48

Post by cjfd »

The main problem with such a stack based language for 'serious' programming would, I think, be the lack of dynamic allocations. The stack is all nice and fine if pieces of memory only need to be preserved inside functions and their children but if memory is to be allocated for an amount of time that is determined at run time there basically does not seem to be anything to do that. Any kind of solution to this would probably be pretty convoluted.

Re: Thoughts on Forth Programming

#49

Post by _cx2w »

cjfd wrote: post #48

The main problem with such a stack based language for 'serious' programming would, I think, be the lack of dynamic allocations. The stack is all nice and fine if pieces of memory only need to be preserved inside functions and their children but if memory is to be allocated for an amount of time that is determined at run time there basically does not seem to be anything to do that. Any kind of solution to this would p…

I'm not sure I follow. The Forth stack is not like the C stack.

Re: Thoughts on Forth Programming

#50

Post by DonHopkins »

cjfd wrote: post #48

The main problem with such a stack based language for 'serious' programming would, I think, be the lack of dynamic allocations. The stack is all nice and fine if pieces of memory only need to be preserved inside functions and their children but if memory is to be allocated for an amount of time that is determined at run time there basically does not seem to be anything to do that. Any kind of solution to this would p…

I wrote malloc.fth for Mitch Bradley's ForthMacs, which ended up in OpenFirmware:

https://github.com/openbios/openfirmware/blob/d5cc657ce81c0f...

    \ Forth dynamic storage managment.
    \
    \ By Don Hopkins, University of Maryland
    \ Modified by Mitch Bradley, Bradley Forthware
    \ Public Domain
    \
    \ First fit storage allocation of blocks of varying size.
    \ Blocks are prefixed with a usage flag and a length count.
    \ Free blocks are collapsed downwards during free-memory and while
    \ searching during allocate-memory.  Based on the algorithm described
    \ in Knuth's _An_Introduction_To_Data_Structures_With_Applications_,
    \ sections 5-6.2 and 5-6.3, pp. 501-511.
Forth systems running on C libraries can also call back to the native malloc/free implementation, but it's nice to have a pure FORTH implementation for embedded applications.
Post reply on HN