[HN Gopher] My history with Forth and stack machines (2010)
___________________________________________________________________
My history with Forth and stack machines (2010)
Author : sph
Score : 49 points
Date : 2023-08-06 19:04 UTC (3 hours ago)
(HTM) web link (yosefk.com)
(TXT) w3m dump (yosefk.com)
| optimalsolver wrote:
| 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
| boesboes wrote:
| 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/La...
|
| Also, check out the GA144: 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 wrote:
| > 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=p
| df&d...
|
| [2]: https://ieeexplore.ieee.org/document/799499
| ithkuil wrote:
| Is the "belt" of the Mill CPU a queue architecture or is a
| queue architecture something else?
| compressedgas wrote:
| Yes. The Mill's belt is a queue. The Mill is a queue
| machine.
| jacquesm wrote:
| I worked for a company that was building a prototype using the
| predecessor (the 'NOVIX'), which was incredibly fast for the
| day.
| jasonwatkinspdx wrote:
| 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 wrote:
| Here's Chuck Moore talking about the 144-core CPUs his
| startup is developing: https://youtu.be/0PclgBd6_Zs
|
| That's an incredible design I would love to get my paws on.
| jasonwatkinspdx wrote:
| 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.
| sph wrote:
| 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...
| runlaszlorun wrote:
| 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.
| sph wrote:
| I was hyped for WASM as well, but the more I read the spec
| and standardisation process, the less I am bullish about
| this as a long-term piece of tech. I would be surprised if
| it is still around in 30 years (compared to stuff like
| UNIX, C or even Forth)
|
| It's closeness to Javascript and the fact that it's
| basically managed by companies that want to keep Web as
| complicated as possible so they can enjoy their monopoly on
| it, turns me off big time.
|
| And lastly, the only thing it has in common with Forth, is
| being stack-based. Computing has become an unsustainable
| pile of buggy abstractions on top of one another, and WASM
| is simply another layer on top this pile of dung, rather
| than a return to the basics. I get why it wants to give
| programmers nothing more than a rounded pair of scissors,
| but then for a glorified VM it's incredibly over-
| engineered. Art has never been created by a committee of
| commercial entities.
|
| I had in mind to write a OS that runs WASM natively, but
| these days I'd rather put a persistent, programmable Forth
| interpreter that gives you full access to the hardware at
| the lowest level, and build up from there.
| jasonwatkinspdx wrote:
| 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.
| 1vuio0pswjnm7 wrote:
| Found in yesterday's https://ftp.funet.fi submission.
|
| 1984. Made with lex.
|
| https://ftp.funet.fi/pub/languages/forth/c-forth.tar.Z
| Corsome wrote:
| 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.
| turndown wrote:
| No. This is a kind of duff's device[0] although it is hard to
| identify. In essence, it's attempting to manually unroll the
| loop's - the while(true) - switch cases, so that if you have a
| PLUS then a DROP right after it can just run linearly(that is,
| fall through to case DROP), not having to go back to the top of
| the loop to go back into the switch statement and then check
| that ip != PLUS to get to case DROP, etc.
|
| 0: https://en.wikipedia.org/wiki/Duff%27s_device
| jonsen wrote:
| You are probably over-interpreting this interpreter.
| benj111 wrote:
| Well it's not stated to be C, and it isn't anywhere near
| complete.
|
| I read it more as C ish pseudo code that just so happens to be
| 'valid' C.
| ks2048 wrote:
| 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/
| optimalsolver wrote:
| Just fyi, typo on this line:
|
| >it this case, it's a built-in
| sph wrote:
| Thanks, that's going on my reading list.
|
| Question to the more educated among us: I read that Apple's UI
| was based on Display PostScript... how similar is it to
| original PostScript, and why was it abandoned?
| mepian wrote:
| Apple's UI is based on Display PDF since macOS 10 (Mac OS X,
| using the old branding), this is the royalty-free replacement
| for Display PostScript of OPENSTEP and NeXTSTEP which became
| the foundation for post-9 macOS after Apple absorbed NeXT.
|
| @DonHopkins is the most knowledgeable person on this topic
| here since he worked on another PostScript-based graphics
| system NeWS for the competitor Sun Microsystems.
| jacquesm wrote:
| I have pinged Don (though there is a fair chance he's
| already sleeping).
| runlaszlorun wrote:
| NeWS is an interesting animal. I loved going through the
| original PDF manuals for it.
| ks2048 wrote:
| That's interesting. I don't know anything about it but maybe
| it means it was based on PS "drawing model" more than the
| actual PS language. (ie the basic primitives and how stroke,
| fill, etc work)
| jasonwatkinspdx wrote:
| It was used as the display language for NeXT and some unix
| workstations. Just googling real quick it was a direct
| dialect of PostScript with the main changes being related
| to using efficient 32 bit integer ids in place of strings
| and similar performance optimizations.
| whartung wrote:
| 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 wrote:
| 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.
| forinti wrote:
| The first thing I ever wrote in Perl was a CGI script that
| printed out a form in Postscript. I wrote ps to draw boxes and
| fit the text the user had entered.
|
| It wasn't pretty to mix perl and ps, and I don't think I have
| ever written anything as wacky as that code, but it was fun.
|
| Folie de la jeunesse.
| riidom wrote:
| For people getting a 503: https://archive.li/xh0aq
| dang wrote:
| Related:
|
| _My history with Forth and stack machines (2010)_ -
| 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 - Oct 2019 (33
| comments)
|
| _My history with Forth and stack machines (2010)_ -
| 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 - Aug 2014 (17
| comments)
|
| _My History With Forth And Stack Machines_ -
| https://news.ycombinator.com/item?id=3963896 - May 2012 (11
| comments)
| LAC-Tech wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| WASM grew out of the earlier asm.js, which was explicitly
| designed as a subset of javascript:
| 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?"
| hintymad wrote:
| 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 wrote:
| If anyone else is interested, https://netflix.github.io/atlas-
| docs/overview/#stack-languag... is the stack language for
| querying.
| runlaszlorun wrote:
| 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. :)
| systems_glitch wrote:
| 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!
| optimalsolver wrote:
| 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/
___________________________________________________________________
(page generated 2023-08-06 23:00 UTC)