Re: HP-PA ABI issues - framepointer handling

["Geert Bosch" <bosch at gnat dot com>]

On Wed, 18 Oct 2000 20:16:49 -0600, Jeffrey A Law wrote:

  More correctly, the ABI defines things that really don't belong in
  the ABI.  ie, the areas where we deviate do not affect the ability to
  mix code from one toolchain to another.  They only affect the lame HP
  unwinder.

Defining a way to unwind is definately something that does belong 
in an ABI, as it is necessary to properly propagate exceptions across
code compiled with different compilers.

  Do a search on the archives.  Most of this stuff was discussed a while
  ago.  I'm certainly open to changes where we don't impact performance
  on the PA, but if we're going to do something that impacts performance
  for the sole purpose of making HP's lame unwinder work, then it'll need
  some discussion.

I am aware of the earlier discussions, but I did not know we don't
even save the framepointer in the right location. There definately
is something between exactly getting all unwinding stuff right, and
not even saving the framepointer in its proper position.
  
  One thing that we should be able to do is at least get the register
  saves into the same place as the HP compiler.  We'll have to define a
  new "hard" register and eliminate it to the FP or SP, it shouldnt' be
  that hard, but I wasn't aware of how to do that way back when I wrote
  the prologue/epilogue code.

I think that's indeed a worthwhile goal, so I'll go ahead and see what
can be done without sacrificing performance. Also, on that note,
it seems that we can save two instructions in the prologue for functions 
that do not do dynamic stack allocations (alloca), by not having to
maintain the GCC convention of passing the framepointer.

  -Geert