Re: HP-PA ABI issues - framepointer handling

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

  In message <20001020141133.F3EF334D8D@nile.gnat.com>you write:
  > Actually our analysis is that following the HP ABI on frame pointer
  > handling (which to me is a *very* legitimate part of the ABI, I am
  > puzzled that you think that frame pointer handling is out of scope
  > for an ABI) may actually improve performance in some cases. More
  > on this later.
Because use/non-use of a frame pointer doesn't affect the calling sequence.
ie, the caller may or may not have a frame pointer and hte callee may or
may not have a frame pointer -- either way the call will work just fine.

A framepointer is mostly a convenience pointer for the debugger, whether or
not a function has a frame pointer does not affect how a function is called
or how it calls other functions in any externally visible way.

  > 4. The ABI places nasty restrictions on how you can generate code.
  > 
  > That is true of many ABI's for example, the horrible convention on  the
  > SPARC that all records of any size must be passed by address rather than
  > in registers, but gcc follows that rule. Sure, it is tempting to thumb
  > your nose at an ABI on performance grounds (many, indeed most, Ada compiler
  > have always done that in the past), but in the long run there are many
  > gains from rigorously following the ABI.
That's completely different as not following this aspect of the ABI would
result in the inability to mix and match code from different compilers.
How parameters are passed and values returned *IS* a part of the ABI and
does need to be strictly followed, no matter how lame they are.

jeff