4 ms·

Hmmm interesting... If it uses that much less silicon then I imagine you could save huge amounts of power. A lot of people would be interested. There must be

by chubot 14y ago

Hmmm interesting... If it uses that much less silicon then I imagine you could save huge amounts of power. A lot of people would be interested. There must be some tradeoff then. Companies are burning huge amounts of cash buying data centers in remote areas because of power. Presumably it's not very hard to compile C to stack code. (Or maybe it won't be as efficient as... Forth?) Or maybe most applications aren't really CPU limited. I remember reading about Chuck Moore's low power processors, but they seem to have mostly specialized applications. In that case it's probably not fair to compare them to x86.

RodgerTheGreat 14y ago
The book actually discusses the problems with running C code on stack machines. To sum up, yes- you absolutely can run C code on a stack machine, but you lose most of the advantages of the architecture. Stack machines make procedure calls very inexpensive and encourage the use of very short procedures with a small number of variables in scope at a given time. The stack operators that are available provide quick access to a few elements at the top of the stacks at the expense of random access to elements that are deeper. Stack-oriented languages like Forth make the programmer aware of this and encourage breaking tasks down in this manner. Idiomatic C has procedures which are at least an order of magnitude longer and have many more values in scope at a given time. This provides a compiler with a fairly uncomfortable and difficult optimization task. Speaking as someone who works with compilers and really likes stack machines, I don't think they will provide much practical value unless programmers are willing to adapt their languages and their approach to programming to the strengths and weaknesses of the paradigm.
- thesz 14y ago
  http://repository.cmu.edu/cgi/viewcontent.cgi?article=1712&context=isr http://repository.cmu.edu/cgi/viewcontent.cgi?article=1712&#... "The algorithm have I developed for intra-block stack scheduling seems to be quite effective, eliminating 91% to 100% of redundant local variable accesses within basic blocks for the small programs studied. Hand-performed global optimization results indicate that significantly better stack scheduling can be done if variables are kept on the stack across basic block boundaries." What is also possible is to discover identical code and automatically generate procedures for it.
- chubot 14y ago
  Yeah that makes sense. I think programming is becoming more and more heterogeneous. So it's possible that stack machines will make a resurgence for some applications, driven by huge power savings. I like Forth but feels a bit "old" to me, i.e. in that it doesn't have common data structures like hash tables. I wonder if a higher level stack language like Joy would run better on a stack machine vs. x86. But once you are higher level, the procedure call time doesn't really matter. I haven't ever programmed any application where procedure call time is a factor... it almost seems like the last thing to optimize.

by chubot 14y ago

RodgerTheGreat 14y ago

The book actually discusses the problems with running C code on stack machines. To sum up, yes- you absolutely can run C code on a stack machine, but you lose most of the advantages of the architecture. Stack machines make procedure calls very inexpensive and encourage the use of very short procedures with a small number of variables in scope at a given time. The stack operators that are available provide quick access to a few elements at the top of the stacks at the expense of random access to elements that are deeper. Stack-oriented languages like Forth make the programmer aware of this and encourage breaking tasks down in this manner. Idiomatic C has procedures which are at least an order of magnitude longer and have many more values in scope at a given time. This provides a compiler with a fairly uncomfortable and difficult optimization task. Speaking as someone who works with compilers and really likes stack machines, I don't think they will provide much practical value unless programmers are willing to adapt their languages and their approach to programming to the strengths and weaknesses of the paradigm.

thesz 14y ago
http://repository.cmu.edu/cgi/viewcontent.cgi?article=1712&context=isr http://repository.cmu.edu/cgi/viewcontent.cgi?article=1712&#... "The algorithm have I developed for intra-block stack scheduling seems to be quite effective, eliminating 91% to 100% of redundant local variable accesses within basic blocks for the small programs studied. Hand-performed global optimization results indicate that significantly better stack scheduling can be done if variables are kept on the stack across basic block boundaries." What is also possible is to discover identical code and automatically generate procedures for it.
chubot 14y ago
Yeah that makes sense. I think programming is becoming more and more heterogeneous. So it's possible that stack machines will make a resurgence for some applications, driven by huge power savings. I like Forth but feels a bit "old" to me, i.e. in that it doesn't have common data structures like hash tables. I wonder if a higher level stack language like Joy would run better on a stack machine vs. x86. But once you are higher level, the procedure call time doesn't really matter. I haven't ever programmed any application where procedure call time is a factor... it almost seems like the last thing to optimize.