|Use the stack less :) firstname.lastname@example.org (2004-04-15)|
|Re: Use the stack less :) email@example.com (Diego Novillo) (2004-04-15)|
|Re: Use the stack less :) firstname.lastname@example.org (SM Ryan) (2004-04-15)|
|Re: Use the stack less :) TommyAtNumba-Tu.Comemail@example.com (Tommy Thorn) (2004-04-21)|
|Re: Use the stack less :) dSpam@arcor.de (Dietmar Schindler) (2004-04-21)|
|From:||SM Ryan <firstname.lastname@example.org>|
|Date:||15 Apr 2004 20:28:57 -0400|
|Organization:||Quick STOP Groceries|
|Posted-Date:||15 Apr 2004 20:28:57 EDT|
# On Intel processors (and on some others, I'm sure), why in heaven's
# name would you use the hardware stack for return addresses,
# arguments, and locals? It makes no sense to me. Maybe it is because
# I'm a Forth
As long as the you always know the size any returned value on the
stack, the result stack can be combined with the protocol stack. Forth
allows a function to return a variable number of words on the stack,
needing the distinction between return and protocol stack. Languages
like Ada or Algol68 that allow a variable sized array to be returned
either use two stack or return the array in the heap.
# It spends 3 instructions (all of which stall the pipeline) to
# initialize, and 2 (very slow) instructions to de-initialize.
# -fomit-frame-pointer does marginally better:
It's a well known problem that stacks are more difficult to pipeline
because the stack top becomes a resource contention. That's part of
why zero address machines like the old Burroughs or HP 3000 have given
way to two or three address machines.
SM Ryan http://www.rawbw.com/~wyrmwif/
Return to the
Search the comp.compilers archives again.