|
|
|
|
|
by 7thaccount
2357 days ago
|
|
I believe there has been a wide variety of successful Forth projects including NASA probes. Forth makes more sense when you can be like Chuck and design your own hardware. At that point Forth is more of a minimalist stack-based philosophy that consists of the minimal hardware + software design to accomplish something. Is his way better? It likely has somewhere near the bare possible code and is very efficient system wise. If you wanted a minimal solution and could devote years to the project, then this is nice. Does it make the best usage of developer time? Obviously not in many cases. In today's business world, you just slap some components together, do minimal acceptable testing, push it out and go to the next thing. Cost is important to the customer, so as long as somebody is willing to do that kind of work, everyone has to. Of course the downside is that we've accreted all this tower of abstractions and complexity going from OS to JVM to libraries and source. We already have tons of COBOL that can barely be maintained. Next will be the large Java and Python codebases. |
|
I actually have designed my own FPGA soft core barrel processor, it's a special blend of register and stack machine. The blend occurs by placing stacks under the registers themselves. I believe this allows a low register count, 2 operand architecture to be more efficient than it otherwise would be, which minimizes opcode size, and sidesteps most the crazy you get when trying to shoehorn most processes into a single stack environment.
But has clear downsides as well, the main one being the stacks can become easily corrupted by any process using them - this is true of any stack machine but you strangely never hear it come up in conversations with Forth types. Stack processors can eliminate much traditional processor state, but the stacks themselves contain state, which is often overlooked.