Howdy, Stranger!

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


Papers on stack => register code

JonathanJonathan Member Posts: 2,914

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.");


  • AlexandrescuAlexandrescu Member Posts: 66
    [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!

  • AlexandrescuAlexandrescu Member Posts: 66
    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.