7 ms·

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:

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/ http://www.greenarraychips.com/

andrewla 9y ago
> 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.
- stefantheard 9y ago
  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.
  - ianai 9y ago
    Round every circle a larger may be enscribed. Don’t be downtrodden but be inspired.
  - e12e 9y ago
    "If I have not seen further, it is because I have been standing in the footprints of giants"
- Cyph0n 9y ago
  > 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.
  - Avshalom 9y ago
    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 https://duckduckgo.com/?q=Moore+okad+forth&t=fpas&ia=web
    - Cyph0n 9y ago
      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.
      - nortiero 9y ago
        And ?
- pmoriarty 9y ago
  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.
- derefr 9y ago
  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.
  - hoosieree 9y ago
    The "stranded time traveler" explanation explains a lot, actually. Including motive.
    - throwaway7645 9y ago
      I also really liked that analogy.
- jackhack 9y ago
  >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.
- e12e 9y ago
  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://colorforth.github.io/video.htm https://web.archive.org/web/20160310112830/http://colorforth.com/video.htm https://web.archive.org/web/20160310112830/http://colorforth... [1] https://colorforth.github.io/install.htm https://colorforth.github.io/install.htm

andrewla 9y ago

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

stefantheard 9y ago
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.
- ianai 9y ago
  Round every circle a larger may be enscribed. Don’t be downtrodden but be inspired.
- e12e 9y ago
  "If I have not seen further, it is because I have been standing in the footprints of giants"
Cyph0n 9y ago
> 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.
- Avshalom 9y ago
  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 https://duckduckgo.com/?q=Moore+okad+forth&t=fpas&ia=web
  - Cyph0n 9y ago
    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.
    - nortiero 9y ago
      And ?
pmoriarty 9y ago
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.
derefr 9y ago
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.
- hoosieree 9y ago
  The "stranded time traveler" explanation explains a lot, actually. Including motive.
  - throwaway7645 9y ago
    I also really liked that analogy.
jackhack 9y ago
>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.
e12e 9y ago
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://colorforth.github.io/video.htm https://web.archive.org/web/20160310112830/http://colorforth.com/video.htm https://web.archive.org/web/20160310112830/http://colorforth... [1] https://colorforth.github.io/install.htm https://colorforth.github.io/install.htm