Hi,

If anyone has read or knows of any good papers on translating stack based code to register based code in a way that achieves good performance, I'd be interested to know of them. I'm particularly interested in cases where there are large numbers of registers (as I imagine there are games you can play when you have 20+ registers to play with that you can't do on the handful you have on an x86).

I know of the normal stack cache stuff, plus remembering if registers hold local variables and re-using those.

I've found plenty of stuff (though have yet to read it), but figured I may as well query the collected experience of the board.

Thanks,

Jonathan

###
for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

This message was edited by Alexandrescu at 2005-9-9 12:40:44

---

As you might noticed already, I am the bad-news-guy: there is little (published)reasearch in that area.
Could it be because they underhestimate this kind of compilers - often thought as toys or some individual-level research...
I am thinking at a stack-based double-cross-compiler - that can be "tuned" to virtually any syntax and semantics and to any hardware as well: by using a mezanine-level PL, that has to compile using the stack-based style transparently.
I guess this is a do-it-ALL-by-yourself stuff.

There are interresting results with compiled FORTH. Try:
http://www.complang.tuwien.ac.at/projects/rafts.html
================================================
((cons(car X)(cdr X))X)
holds(X,P):-P(X);holds(Y,P),IsA(X,Y).

Any (more) questions? SHOOT!

The FORTH stuff was ment to let you know about how a good and simple stack-based code works. As for converting it into a register-based...

Well, I see two possible approaches:

1- each register can hold the last element on its associated stack (or a pointer to that element, of course - C/Pascal issues involved here). So the register-based code could handle as many stacks as register-stack pairs are made available.
Although this approach looks like it emproves something, I think it just multiplies the number of stacks the code can handle simultaneously, but there is a high price to pay usually; and that price comes dued to the lack of stack-management-optimisation for other register types than stack-dedicated registers (SS, SP, BP...)

2- registers could be thought as holding the last "n" cells on the unique stack they are associated with; so you'll get a nice stack mirroring. That will deffinitely work faster since it's "cheaper" to use any general-purpose registers contents than any memory zone's contents - even handled by specially assigned registers (stack registers). Of course the registers have to be oragised circularly - for best application's performance... that will make the worst compiler's performance

How about the second approach?
================================================
((cons(car X)(cdr X))X)
holds(X,P):-P(X);holds(Y,P),IsA(X,Y).

Any (more) questions? SHOOT!