3 ms·

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 m

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.

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.