Papers on stack => register code


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. :-)



(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");


  • [b][red]This message was edited by Alexandrescu at 2005-9-9 12:40:44[/red][/b][hr]
    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:
    ((cons(car X)(cdr X))X)

    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)

    Any (more) questions? SHOOT!

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


In this Discussion