Hacker News Reader

Comment by Avshalom | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com