Hacker News Reader

Comment by orf | Hacker News Reader

> If you have read any of Chuck Moore's work, you know that he is an extreme programmer in the literal sense of the word: a unique philosophy that embraces small, fast, self-contained programs in a spare language and an impressive development environment

I haven't read any of his work, what is impressive about his development environment?

View on HN

He designed CPUs from scratch using a bare-bones minimal Forth (ColorForth) as his preferred way of writing code. The resulting chipset is utterly fascinating: http://www.greenarraychips.com/

> from scratch

This is even understating it -- it's not like he used existing software to lay out the chip, and then ran tests using PSPICE to verify the functionality. He wrote his own chip design software and analog simulator, and designed the chip in his own environment, and created the CPU, the GA144: a working 144-core processor designed to run "ArrayForth", a parallel version of Forth that he designed and authored, just as he designed ColorForth, and just as he designed, once upon a time, the language known as Forth.

Any of the tasks above seem like it would be a reasonable accomplishment for a good programmer. Combined, they make me question whether I even qualify as a developer by this standard, and make me wonder whether I should take a year off of development and just really learn Forth.

Your ending summary was exactly my thought process as I read the first paragraph. I essentially went through the 5 stages of grief as I realized I am no longer a developer.

Round every circle a larger may be enscribed. Don’t be downtrodden but be inspired.

"If I have not seen further, it is because I have been standing in the footprints of giants"

> He wrote his own chip design software and analog simulator

I'm going to need a citation for that. I browsed through the website and wasn't able to find anything at all mentioning the development of a full EDA software suite. There are only a handful of companies in the world that can build and maintain a full HDL + synthesis + P&R + layout + verification toolchain...

Also, I would be interested to know what kind of process the GA144 is fabbed with.

I don't know how much of the usual stack it accounts for or if it specifically was used for the GA144 but they're referring to OKAD, often talked about as in hundreds/thousands of lines of colorforth https://duckduckgo.com/?q=Moore+okad+forth&t=fpas&ia=web

Before I put on my cynical hat, I'd like to say that it's pretty impressive stuff for a one-man shop in the 90s.

-----

So it seems like OKAD is basically a layout editor, simulator, DRC checker, and GDSII compiler. The simulator uses a very simplistic transistor model that would only work at very old process nodes (>350nm?) due to the low impact of parsitics and leakage.

Not even a moderately complex digital chip from the mid-90s could be designed and verified using such a simplistic toolchain.

To provide a software analogy, Chuck wrote an assembler for a custom assembly dialect targeting e.g. x86, and then directly used that assembler to build an operating system kernel. Given the absence of "higher-level" constructs, the resulting OS will never be as complex as something like an NT kernel, especially due to the difficulty of testing and verification.

Going back to circuit design, OKAD will never be able to design a complex digital chip on a state-of-the-art process. It's really nothing more than a simplistic EDA toolchain that would only work on simplistic circuits and fabrication processes.

A modern EDA toolchain from e.g. Cadence is many orders of magnitude more complex.

And ?

TL;DR Not really as impressive as it was made out to be.

You're entirely missing the point made by Chuck Moore and by extension probably don't understand why his way of looking at programming and the Forth language in particular are a big deal even this long after their invention.

This kind of minimalism and stripping things down to their essence is a powerful tool to allow you to focus on what matters rather than at all those things that don't really matter. If you don't actually need 4 GHz chips and billions of transistors to get the job done then why would you?

Reliability and simplicity go hand-in-hand.

> This kind of minimalism and stripping things down to their essence is a powerful tool to allow you to focus on what matters rather than at all those things that don't really matter. If you don't actually need 4 GHz chips and billions of transistors to get the job done then why would you?

I agree entirely. I just wanted to point out that it's not accurate to equate what Chuck designed (i.e., OKAD) to a modern EDA toolchain and technology node.

If it works for him, then great!

Nobody equated that. The time when he made his is decades ago, so obviously nothing from those days compared to a modern EDA toolchain and associated bits and pieces.

I think you subconsciously added the 'modern' in there somewhere and then argued against that.

You might actually be right. When I read this:

> He wrote his own chip design software and analog simulator

I immediately thought of a modern toolchain. Had I known that this was done decades ago, I might have reacted differently.

Nonetheless, even decades ago, both Cadence and Synopsys likely had pretty advanced tools under development. I may be mistaken though.

Heh, I remember running Solo 2030 on Motorola-based Sun workstations almost 25 years ago...

Moore mentioned these in passing at the end if the link https://colorforth.github.io/1percent.html He was stressing the solution fits the problem. Not a solution which can cover/contain the problem

And here's why that matters. Below is the complete source of a Forth block editor. This editor is more than sufficient to write an OS with, although of course emacs or vim would be better. That is pretty awesome.

Forth is a language in which it's realistic for each programmer to have his own custom editor. That's even more awesome.

    | RetroForth Block Editor (http://www.retroforth.org)
    | * Released into the public domain *
    |
    | This is the block editor from RetroForth Release 9.2.1
    | It splits the normal 1k block into two smaller 512-byte blocks,
    | the one on the left for code, and the one on the right for
    | documentation/comments. Both are displayed side by side.
    |
    | It makes use of some features specific to RetroForth, so it
    | will not work on an ANS FORTH system without changes. 
   
   
    tib 1024 + constant <buffer>
    128 variable: <#blocks>
    <buffer>  variable: b0
    variable  current-block
   
   
    : there b0 @ ;
    : #-of-blocks <#blocks> @ ;
   
   
    : new there #-of-blocks 512 * 32 fill 0 current-block ! ; new
   
   
    : (block) @current-block : block 512 * there + ;
    : (line) 32 * (block) + ; 
   
   
    : p 2 current-block -! ;
    : n 2 current-block +! ;
    : d (line) 32 32 fill ;
    : x (block) 512 32 fill ;
    : eb (block) 512 eval ;
    : el (line) 32 eval ;
    : e 16 for 16 r - el next ;
    : s !current-block ;
    : i 0 swap : ia (line) + lnparse rot swap move ;
    : \ 1 s e ;
   
   
    loc:
     : | '| emit ; 
   
   
     : row dup 32 type 32 + ;
     : left# -16 + negate dup @base <if space then . ;
     : right# negate 32 + . ;
     : code|shadow row | swap row swap space ;
     : rows 16 for r left# code|shadow r right# cr next ;
     : x--- 2 for ." +---:---+---:---" next ;
     : --- space space space x--- | x--- cr ;
     : blocks @current-block 1+ block @current-block block ;
     here ] --- blocks rows 2drop --- ;
    ;loc is v
   
   
    : edit [[ clear v ]] { is ui } ;

> : right# negate 32 + . ;

This is an example of "ugly" Forth code. It's ok here to make the code as short as possible.

In reality I would write (educational) Forth code this way. The texts in parentheses are comments.

  ( compute Hypotenuse sqrt[a²+b²] )
  : hypo       ( a  b   )
    swap       ( b  a   )
    dup *      ( b  a²  )
    swap       ( a² b   )
    dup *      ( a² b²  )
    +          ( a²+b²  )
    sqrt       ( result )
  ;

  ( Application:  1.2 3.4 hypo )

Isn't the first swap unneccesary?

Of course. You learn quickly ;-)

Aren't a lot of us already doing what matters, but just not articulating it the same way?

I collaborate on a team, so we use one documentation standard and one coding style. We've stripped down our coding and commenting styles to the bare essential--one style that works across the whole team, across the lifespan of the project.

The business that pays our team pays for what customers want. Every once in a while a new guy on the team will write something no one wanted, and we end up chucking it. We're stripping down the project code to the bare essentials necessary to make money.

I think what Chuck Moore brings is not so much a plain ol' minimalism, but a nostalgia for a wild west "one man in a garage" tech scene that never really existed, at least not the way we like to imagine it did, because we live in a world driven as much by money as by love of cool new things.

Not to say he doesn't do cool things, but I could do cool things if I didn't have to answer to business constraints, my fellow team members, and so on.

>>modern EDA toolchain from e.g. Cadence is many orders of magnitude more complex.

Moore considers that a mangitude of bugs not features.

http://yosefk.com/blog/my-history-with-forth-stack-machines....

Has some good quotes on it if you scroll down to the end

>Given the absence of "higher-level" constructs, the resulting OS will never be as complex as something like an NT kernel

i wonder whether you've worked with Forth - in my view of Forth (spent 1987-89 mostly in Forth running on 8088 clone based terminal of USSR clone of IBM 360, so Forth is my second language after mandatory Pascal and the first true "computer" love really) what you said is a huge advantage and natural characteristic of Forth, not a deficiency. Everything in the Forth world is like Salvador Dali's clock face plates - flexible/pliable/flowing and you build whatever "higher-level" constructs and complexity levels you need right now and leave them behind the moment you don't need them anymore, create and destroy worlds as you go... In comparison to that the static monstrosity like NT kernel is just dead dusty world of an ancient complex tech civilization who died off under the weight of its own complex tech.

To Cyph0n below: man, as an enterprise programmer for 25 years i completely understand and agree with you. As that Forth programmer enjoying it 3 decades ago i can only say to you - you just don't get it :)

That was an analogy attempting to explain what OKAD does. The kernel represents the circuit being designed, while the assembler represents the OKAD toolchain.

The goal of the analogy was to demonstrate that OKAD is not suitable for designing large circuits, just like using assembly to write a modern kernel is not practical.

Well, presumably it’s not meant to be suitable for designing large/complex circuits, but rather to solve just the specific problems that Moore had when he wanted to make a chip. That’s an essential part of Forth philosophy: write only and exactly what you need. Forth itself is designed this way, to be the minimal useful tool you can bootstrap in a few dozen instructions on a chip with almost no resources.

> Not even a moderately complex digital chip from the mid-90s could be designed and verified using such a simplistic toolchain.

Maybe he didn't want to design a moderately complex chip to begin with? His 144 core chip is likely very simple. OKAD may have been sufficient.

Oh N.B. I just looked it up the GA144 is fabbed at 150nm

> 'm going to need a citation for that.

"My VLSI tools take a chip from conception through testing. Perhaps 500 lines of source code. Cadence, Mentor Graphics do the same, more or less. With how much source/object code?

– Chuck Moore, the inventor of Forth

Source: http://yosefk.com/blog/my-history-with-forth-stack-machines....

500 lines are actually possible since Forth words are threaded. That means, any new defined word w can take advantage of all available predefined words. Follwing words can take advantage of w, etc. Forth words are not just simple procedures but they can also comprise new syntax structures. Forth words can be "procedures" or "macros", and both can be mixed freely.

Threaded code was the main reason why Forth was so successful in the first years when memory costs were a real issue.

I've heard of the wonders of Forth for many years -- about how it was just as good at metaprogramming as Lisp, how it was very powerful and yet extremely light-weight, about how you could run it on bare metal, and write your own OS and utilities in a fraction of the time it would take in other, more well-established languages, and so on.

I got really excited about it, and when I finally started learning it, I had very high expectations and really wanted to love it. Unfortunately, overall those expectations were not met. I did find the experience enlightening, as it was a pretty different way of programming, and I love to gain new perspectives. That said, I was disappointed to find Forth was mostly an obfuscated, write-only language.

Many in the Forth community preach that one should write only very short, well-documented "words" (ie. functions) that are clear and easy to understand. But the reality in the Forth code that I've seen was a lot of long, poorly documented, convoluted words which were a nightmare to read or debug. Granted, this was in the open source community. I've heard that the code in commercial Forths is in a much better state, but I don't have any experience with that.

One also seemed to have to write a lot of one's own code in Forth, because there just really weren't that many libraries you could lean on. I guess I prefer the more batteries included approach. I've also heard even Forth fans admit to me that writing Forth was painful and that the point of using Forth was to write yourself a higher level language as quickly as possible, so you don't have to work in Forth.

Well, I'm personally not all that interested in writing languages myself, and am quite content to use a pre-written language where all the hard and boring work was already done for me by someone else, and I can just use the nice higher-level features that already exist in these high level languages.

I guess if you're on a resource-starved system like some tiny microcontroller, using Forth over assembly might make sense. But as I usually work on relatively powerful desktops or servers, I don't really see the point of using Forth there at all. I'd just rather save myself the pain and hassle, and use any of number of existing high level languages to begin with.

As for Moore's work, I kind of see it like the work of someone building the Eiffel Tower out of toothpicks. It's certainly an impressive accomplishment. But how practical is it?

I'm also not sure how much Moore subscribes to what have become well-accepted software engineering practices such as having good documentation, clarity of code, and testing. It seems like he prefers to sacrifice all at the altar of size and performance. That's great as far as it goes -- if that's all that's important to you and you can make it work for you (and he certainly made it work for him). But looking around at the mountains of poorly documented hacky spaghetti code in the rest of the world, it just seems like following that path leads to an unmaintainable, buggy mess.. unless maybe you are Chuck Moore and can make it work anyway.

Forth is no different from other languages in that you can write good code and bad code in it. The 'Forth way' is not always intuitive and in that it fails from the purpose of being a language friendly to newcomers, it's a bit like being dumped on someone else's farm without power, water or sewage and a pile of tools and raw materials for you to use.

Taking a step down like that when coming from a modern environment is really hard. But when looked at from the other direction, as a step up from assembler and a way to become much more productive while at the same time reducing the amount of space bugs have to hide in it makes a lot more sense.

But in the present day it's no longer very useful unless you are doing something embedded or if you want to entertain yourself with an eternal match of code golf.

Forth IS different in one way, from most other languages. The syntax doesn't mark which parameters are being passed to which functions. In C for example you have parentheses and commas that provide that information to the reader. The marking of parameters-to-functions helps most readers read a program and determine its meaning.

In some cases it doesn't matter which parameters are going to which functions, and the reader can get a sense or enough of a sense, from the choices of names the programmer made. You can get by without knowing.

But in many cases it is vital to know which parameters are being passed to which subroutine, in order to understand an algorithm. For most people, having to puzzle and re-puzzle this out while the program is being studied is too much extra work or extra ambiguity, or, they just don't buy having to put up with it, given the ready alternatives.

Those specific markings -- parentheses around function calls -- makes a big difference in readability overall.

I've often thought about an editor for a stack/concatenative language that makes the arity of words clearer. like when you select a word it highlights which of the previous words in the definition it's consuming.

I don't know if it would work for forth - too low level - but for something like Factor I could see it being really useful.

I’m surprised this is the only reference to Factor (http://factorcode.org).

I think the important distinction-- and the reason that I never got very far in Forth myself-- is that with Forth, you don't have the pile of tools and raw materials, but instead a forge and some ingots of various metals. You really do often end up rebuilding even things you'd normally consider simple library functions in most other languages.

I feel like a desire to program in Forth is more the consequence of being a crazy-in-the-good-way programmer, rather than something that aids in becoming that sort of programmer.

Moore, from my perspective, decided to bootstrap a computing architecture from as primitive and restrictive of a starting place as he could come up with. Forth makes sense as a language if you imagine yourself as a time-traveller stranded in the 1970s (or even earlier!), trying to get a "foothold" into your futuristic programming environment using the wimpy computers of the era, so that you could design and build the hardware on which would run the software that you actually wanted to write. (Which would, in turn, fix your time machine or whatever.)

Learning Forth isn't really a step on that path. Rather, designing your own minimalistic language under the constraint that it'd have to 1. run on the wimpiest hardware you can imagine, but 2. allow you to be productive in the rest of the bootstrapping process — that's the first step on the path to being Chuck Moore.

The "stranded time traveler" explanation explains a lot, actually. Including motive.

I also really liked that analogy.

>Any of the tasks above seem like it would be a reasonable accomplishment for a good programmer.

I think that's understating it. I would consider any of those accomplishments to be a monumental undertaking. Combined, it is legendary.

If there is ever any doubt as to the existence of the 100x programmer - I would think this guy is proof. Somebody who creates their own chip design software as a means to creating their own multicore processor to run their own language, faster, is a motivated genius.

You're still underselling it; Colorforth is a traditional forth: it's the OS as well as the application[1] - it comes with drivers to write your progress to floppy disk.

One of my favourite blog post by Moore is where he builds up to generate the vga signal needed to drive his monitor from the ga-144. Sadly the code links are dead, even at archive.org - but the text remains:

https://colorforth.github.io/video.htm

https://web.archive.org/web/20160310112830/http://colorforth...

[1] https://colorforth.github.io/install.htm

Reply on news.ycombinator.com