3 ms·

> In 1983 Chuck founded Novix, a company whose goal was to design a processor that was optimal for use with FORTH, a true stack processor. C started as a langu

> In 1983 Chuck founded Novix, a company whose goal was to design a processor that was optimal for use with FORTH, a true stack processor. C started as a language that was designed to take advantage of an existing processor to produce fast code. That has worked spectacularly. It seems, however, going the other way by first designing a language and then making a processor to make it fast does not work out. Other examples are the Lisp Machines and Java Processors.

mumblemumble 7y ago
I would guess that's for economic reasons rather than technical ones. I think that lispm were considered a great technical success by many people. The problem was that they were a lot more expensive, and much more limited in what you could do with them (not quite "You can program in any language as long as it's lisp, but you get the idea). That constrained them to a relatively tiny market, which in turn limited the amount of money that could go into R&D on the technology. So it was doomed to fall behind. Java processors, I'm still not sure what the target market there was. It's easy to imagine at least an academic market for lisp machines, particularly during the 1980s and perhaps the early 1990s. But, particularly in a post-1995 software environment, it's hard to imagine a large-scale (as in, not embedded) computing project that can reasonably commit itself to Java, and it's also hard for me to imagine an embedded application where Java would be preferable to a low-level language. Which is also more of an economic problem - they might have worked really well from a technical perspective, but that doesn't mean they weren't a solution in search of a problem.
- mud_dauber 7y ago
  I joined the RTX team at Harris Semi after grad school. The only devt environment they could offer customers was (as I remember it) completely Forth-based - the barrier to entry was awfully steep, even for greenfield projects.
  - astrobe_ 7y ago
    I learned Forth by myself with Pygmy Forth (no Internet, no book, just the docs of that system) when I was 15 or so. It was my third language after Basic and assembler. I believe that the challenge of Forth is not to learn it, but to unlearn the rest. It is difficult to forget what you know. It's difficult to forget about dynamic memory allocation, classes, local variables, type checking... And frustrating too. It's like video games. When I was a kid/teen, I could do over and over again a level until I succeeded. Not today. I would lose patience and bitch about the poor game/level design because I think I know better. I am more often wrong than right on this. Adult programmers and engineers are like that. They think they know better, so when something is difficult for them, they blame it on the language. They don't have the really open mind kids have. If there's a barrier to entry, it is not in Forth.
    - mud_dauber 7y ago
      I think I agree with you. Forth was (fortunately IMO) the first language I really grokked after undergrad. Before that it was assembly, Apple Basic & (shudder) Fortran. I had zero exposure to CS 101. So Forth warped my brain in all the right ways.
- dri_ft 7y ago
  > I would guess that's for economic reasons rather than technical ones. I think that lispm were considered a great technical success by many people. Hey, an economic failure's a failure. The technically perfect machine that doesn't exist because no market would buy it... doesn't exist.
vimota 7y ago
It's probably a stretch but the closest thing to this today is TPUs being built for Tensorflow.
upofadown 7y ago
The opposite happened once C became a thing. Processors started offering features to make C programs faster. The stack frame support that first showed up on 8086 processors comes to mind. At any rate, what we run these days are for all practical purposes C machines...
- Taniwha 7y ago
  stack frame support was around long before the x86 - VAXs are a great example (B6700s a more extreme one) - the first VAXs were created before C had become popular or wide spread
- jecel 7y ago
  Frame pointers help Pascal. While C can also used them to make nicer assembly code (a given variable always has the same offset) it can work well without them. RISCs are very good C processors, but it is possible to do even better: https://en.wikipedia.org/wiki/AT%26T_Hobbit https://en.wikipedia.org/wiki/AT%26T_Hobbit
ahefner 7y ago
Chuck never hesitated to change the language to fit the CPU. His various Machine Forth dialects definitely co-evolved with the hardware they targeted. In terms of making it fast, I think he was fairly successful within the constraints that these are small CPUs, not superscalar, no giant caches, etc.

mumblemumble 7y ago

I would guess that's for economic reasons rather than technical ones. I think that lispm were considered a great technical success by many people. The problem was that they were a lot more expensive, and much more limited in what you could do with them (not quite "You can program in any language as long as it's lisp, but you get the idea). That constrained them to a relatively tiny market, which in turn limited the amount of money that could go into R&D on the technology. So it was doomed to fall behind. Java processors, I'm still not sure what the target market there was. It's easy to imagine at least an academic market for lisp machines, particularly during the 1980s and perhaps the early 1990s. But, particularly in a post-1995 software environment, it's hard to imagine a large-scale (as in, not embedded) computing project that can reasonably commit itself to Java, and it's also hard for me to imagine an embedded application where Java would be preferable to a low-level language. Which is also more of an economic problem - they might have worked really well from a technical perspective, but that doesn't mean they weren't a solution in search of a problem.

mud_dauber 7y ago
I joined the RTX team at Harris Semi after grad school. The only devt environment they could offer customers was (as I remember it) completely Forth-based - the barrier to entry was awfully steep, even for greenfield projects.
- astrobe_ 7y ago
  I learned Forth by myself with Pygmy Forth (no Internet, no book, just the docs of that system) when I was 15 or so. It was my third language after Basic and assembler. I believe that the challenge of Forth is not to learn it, but to unlearn the rest. It is difficult to forget what you know. It's difficult to forget about dynamic memory allocation, classes, local variables, type checking... And frustrating too. It's like video games. When I was a kid/teen, I could do over and over again a level until I succeeded. Not today. I would lose patience and bitch about the poor game/level design because I think I know better. I am more often wrong than right on this. Adult programmers and engineers are like that. They think they know better, so when something is difficult for them, they blame it on the language. They don't have the really open mind kids have. If there's a barrier to entry, it is not in Forth.
  - mud_dauber 7y ago
    I think I agree with you. Forth was (fortunately IMO) the first language I really grokked after undergrad. Before that it was assembly, Apple Basic & (shudder) Fortran. I had zero exposure to CS 101. So Forth warped my brain in all the right ways.
dri_ft 7y ago
> I would guess that's for economic reasons rather than technical ones. I think that lispm were considered a great technical success by many people. Hey, an economic failure's a failure. The technically perfect machine that doesn't exist because no market would buy it... doesn't exist.

vimota 7y ago

It's probably a stretch but the closest thing to this today is TPUs being built for Tensorflow.

upofadown 7y ago

The opposite happened once C became a thing. Processors started offering features to make C programs faster. The stack frame support that first showed up on 8086 processors comes to mind. At any rate, what we run these days are for all practical purposes C machines...

Taniwha 7y ago
stack frame support was around long before the x86 - VAXs are a great example (B6700s a more extreme one) - the first VAXs were created before C had become popular or wide spread
jecel 7y ago
Frame pointers help Pascal. While C can also used them to make nicer assembly code (a given variable always has the same offset) it can work well without them. RISCs are very good C processors, but it is possible to do even better: https://en.wikipedia.org/wiki/AT%26T_Hobbit https://en.wikipedia.org/wiki/AT%26T_Hobbit

ahefner 7y ago

Chuck never hesitated to change the language to fit the CPU. His various Machine Forth dialects definitely co-evolved with the hardware they targeted. In terms of making it fast, I think he was fairly successful within the constraints that these are small CPUs, not superscalar, no giant caches, etc.