Groups | Search | Server Info | Login | Register

Groups > comp.arch > #6482

Re: Architecting a return address stack

Show all headers | View raw

This doesn't sound so different from UltraSPARC. Has anybody written a LISP
or other language to optimise tail recursion in this environment?

torbenm@diku.dk (Torben Ægidius Mogensen) wrote:

> "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