[HN Gopher] My history with Forth and stack machines (2010)
___________________________________________________________________
My history with Forth and stack machines (2010)
Author : homebrewer
Score : 63 points
Date : 2024-12-28 16:34 UTC (6 hours ago)
(HTM) web link (yosefk.com)
(TXT) w3m dump (yosefk.com)
| DonHopkins wrote:
| I just posted some historical info about Chuck Moore's work for
| HOMER and Associates on a real time visual mixing console that
| produced many music videos that ran endlessly on MTV back when
| they actually played music videos, and special effects for
| blockbuster films like RoboCop and Total Recall to the discussion
| about abstractions:
|
| https://news.ycombinator.com/item?id=42532404
| mud_dauber wrote:
| I got a taste for this years ago at Harris Semi. Grokking their
| RTX microcontrollers was a ton of fun. (Not so much for
| customers, who'd never seen such a thing.)
| romforth wrote:
| I have ported Forth to a dozen small microcontrollers and my
| experience writing much of the bootstrap code in Forth tells me
| that you are better off coding Forth in a "vertical" style (ie
| one word per line with stack picture comments), rather than the
| terse "horizontal" code of "everything on one line" that many of
| the folks using Forth (including @yosefk, the author) seem to
| prefer.
|
| Given how close Forth is to assembly (seen from an implementer's
| point of view) it makes sense to write Forth in a "vertical"
| style which reflects the "vertical" style in which assembly code
| is written. This has the advantage that the "stack picture
| comments" on each line of code can stand in for Hoare triplets so
| that the code and its - I'll call it - "proof" can be written
| hand in hand at the same time.
|
| This is how all of the Forth code that I've written in
| https://github.com/romforth/romforth is structured.
|
| It does make the code appear less compact though so you are not
| going to win any code golf prizes.
| Lerc wrote:
| Is there any editor/IDE support for stack state visualisation?
|
| A text display with an auto pretty printed view would serve
| people who like both code styles well.
|
| A newline per stack reducing operation with the next line
| indented by stack depth would make it close to your style and
| could be quite automatic.
| romforth wrote:
| Something like an automated proof assistant to help annotate
| the stack while coding would be awesome, but I'm not aware of
| any.
|
| These might be famous last words, but if switching between
| compile/interpret modes is ignored, I think it shouldn't be
| too hard to implement it though.
| cess11 wrote:
| Adjacent rather than a Forth, but take a look at Factor.
|
| https://factorcode.org/
| volemo wrote:
| We removed explicit arguments from the language so you can
| write comments with arguments after every function call. :D
| nxobject wrote:
| I'll agree with a lot of his critiques, but one of his small ones
| that surprisingly echoed a lot of frustration was the dictum to
| prefer small definitions.
|
| > Quoting Chuck Moore:
|
| > Forth is highly factored code. I don't know anything else to
| say except that Forth is definitions. If you have a lot of small
| definitions you are writing Forth. In order to write a lot of
| small definitions you have to have a stack.
|
| It seemed like apologetics and a making a virtue out of
| necessity, given the fact that I don't have the capability to do
| stack acrobatics in my head live. The only way to be able to read
| a function in my head, without taking a pencil to paper _was_
| small functions. But I found that clashed with the ways some
| algorithms and procedures naturally expressed themselves in
| longer multi-step style, and actually ending up being more
| verbose and tangled with multiple top-level definitions.
|
| It turns out that local variables that compile to C-style
| indirect (SP + i) accesses are only mildly more expensive than
| stack acrobatics, but still gave the flexibility of Forth-style
| metaprogramming. [1]
|
| Ultimately, the author's points about the "Forth philosophy" but
| not Forth-the-language itself (and extremely spare code) ring
| true to me.
|
| Given my limitations, life is too short to work to have as
| minimalist an implementation as you'd like, and to desire to have
| a interactive development environment in <128k. For me, it's hard
| enough to implement the "subject" that I'm programming
| algorithmically/data-driven-ly/amortizing-computation-ly
| efficiently.
|
| [1] https://www.novabbs.com/devel/article-
| flat.php?id=26347&grou...
| nalsirety wrote:
| It's easier to approach Forth as assembly-like than C-like.
|
| That is, why are you factoring the code to use the stack when
| you have globals?
|
| (Mumble mumble structured program, recursion, reuse)
|
| If you move towards a global-first approach(which is what Chuck
| Moore seems to have moved towards, from anecdote), what changes
| is that you can substitute the word defining the variable for
| another word, later down the line, that adds the context,
| indirection and error handling you need. The mechanism can be
| added without changing how the word is being used, and you can
| still write a divide-and-conquer kind of algorithm in this way,
| it's just more classically imperative in style, with more
| setting of mutable global temporaries and every byte of
| bookkeeping directly accounted for.
|
| Part of the minimalist freedom in Forth is that it is agnostic
| to whether you're using the stack or the dictionary. If you
| want the word to be unambiguously about a particular space in
| memory it makes sense to define it first in terms of "it
| accesses this static location" instead of "it consumes three
| things on the stack and shuffles them around and indirects one
| to a memory location and adds the other two", because that
| inclines all the words to be about the stack. Take the
| primitive approach - the one that maps well to assembly - first
| and see how far it goes. You stay in control of how you're
| extending the language that way. C preempts that because the
| compiler hides the stack manipulation, so the semantics of the
| function will default towards locals, and then further
| extension is guided around fitting it into that.
|
| (And it's true that the compiler gets you to an answer faster,
| and black-boxes the interface, so you can use code without
| reading code - and that is coming at the expense of precision
| around details like this. Forth is probably not the right way,
| if it's Conway's law that you're up against.)
| vok wrote:
| I think that "Good Forth programmers arrange things so that they
| flow on the stack" has analogs in other languages. For example,
| arranging things in J so that short tacit expressions naturally
| provide the functions you need.
| abrax3141 wrote:
| You want to be truly amazed, check out Newell's IPL-V, which is a
| machine language for a stack machine, developed in the 1950s and
| used to implement the first AIs. It had every idea n Lisp except
| the parens.
| codr7 wrote:
| I feel like Forth will always have a place in embedded contexts.
| And it's a good language to start with when learning how to write
| interpreters/compilers.
|
| The second you start building higher level apps in Forth, you
| lose most of its advantages from my experience.
|
| While usable as an in-app scripting language, I would pick Lisp
| any day.
___________________________________________________________________
(page generated 2024-12-28 23:00 UTC)