Re: nightmares with biased stack pointers

[Jeffrey A Law <law at cygnus dot com>]

  In message <199709131024.GAA10195@jenolan.rutgers.edu>you write:
  > The problem is that sparc64 is the only target which has whats called
  > a 'biased' stack pointer.  %sp really doesn't point to the stack, it
  > points to the stack minus 2,047 bytes.
Weird, but I understand how it could be useful.  The mn10300 cpu
handles this slightly differently -- memory references from the
stack pointer are unsigned, thus doubling the the effective
memory referencing range for SP accesses.

Of course SP isn't a general register, so this hackery is
pretty simple.

  > (STACK_BIAS is the aforementioned 2047 byte bias %sp has,
  >  FIRST_PARM_OFFSET is a known aligned offset from that frame)
  > 
  > That code is correct and unoptimized.  If I turn on any optimizations,
  > the combiner looks at that and determines something along these lines:
  > 
  > 1) Hey, I know how %sp must be aligned
  > 2) Hey look, two redundant addition instructions, combine 'em
  > 3) Hey look, taking into account the known alignment of the stack
  >    frame and the "add sp, const, reg; srlx 4; sllx 4;" sequence,
  >    I can determine that this is really an alignment of the 'constant'
  >    so I can merge this into a constant operation and blow the two
  >    shifts away.
Interesting problem; what would happen if you declared the stack was
unaligned, and made sure in the backend prologue/epilogue routines
(and parameter passing) to make sure that you always made frames
that were multiples of the old alignment?

jeff