Groups | Search | Server Info | Login | Register

Groups > comp.arch > #6468

Re: Architecting a return address stack

Show all headers | View raw

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

> While an architected return address stack can provide a modest
> benefit from early return address determination (a predictive
> return address stack provides most of this benefit but is
> predictive, of limited size, and stores information redundantly)
> and protection from return address overwriting, such introduces
> some overhead which may make it less attractive at the very low
> end (the level of, e.g., ARM Cortex-M0+) and at the higher end
> (providing an additional OoO execution mechanism for such
> special purpose registers and memory accesses could be a
> nuisance, though being highly decoupled from ordinary
> execution should constrain complexity it seems).

One possible benefit from a hardware return stack is to execute the
continuation after the return concurrently with the call.  Instead of
saving registers on the return stack, the caller gets its own copy of
the registers (through renaming) and is executed in parallel with the
continuation, synchronising through the return-value register.  If there
is not enough registers (or threads) for the new call, a thread is
spilled to a stack to make room.

In a normal memory model, the continuation can continue until either it
accesses the return value register or a memory location (as this might
potentially be overwritten by the called procedure), but you could have
a more "functional" memory model where it is assumed that the called
procedure does not modify memory reachable by the caller (except through
a pointer in the return-value register).  This would allow for more
parallelism.  You could have two kinds of memory-access instructions:
Functional and imperative, where a thread would stop on an imperative
memory access until all calls higher in the stack are done, but where
functional memory accesses would not block.  Enforcing that functional
memory accesses do, indeed, behave in a write-once-read-many way may be
expensive, but you could leave that to the compiler to ensure and simply
say that behaviour is undefined if this is not done.

	Torben

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Architecting a return address stack "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-03-27 17:35 -0700
  Re: Architecting a return address stack MitchAlsup <MitchAlsup@aol.com> - 2012-03-28 08:57 -0700
    Re: Architecting a return address stack ggtgp@yahoo.com - 2012-04-04 12:03 -0700
      Re: Architecting a return address stack MitchAlsup <MitchAlsup@aol.com> - 2012-04-05 09:08 -0700
  Re: Architecting a return address stack torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-10 12:23 +0200
    Re: Architecting a return address stack Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-10 22:22 +0200
      Re: Architecting a return address stack torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-12 09:52 +0200
  Re: Architecting a return address stack jacko <jackokring@gmail.com> - 2012-04-14 08:32 -0700

csiph-web