🚀 go-pugleaf

In article k04@wcap.centerline.com, chase@centerline.com (David Chase) writes:
>In article mca@engnews1.Eng.Sun.COM, clamage@Eng.Sun.COM (Steve Clamage)
>writes:
>> Suppose that function entry and exit are not atomic operations, which is
>> the case on all systems supporting C++ that I am aware of. The "critical
>> structure" is the stack frame. If asynchronous interrupts can occur, and
>> if you are going to require well-defined exception behavior from signal
>> handlers, then you must lock the entirety of every function preamble and
>> postamble. (You cannot know that an external signal won't occur.) That
>> requirement not only slows down function calls, it adds to interrupt
>> latency.
>
>As near as I can tell, the best way to do this is to slightly enhance a
>PC-range-based exception-handling specification.  I was pushing for
>this for the Sparc V9 ABI when I worked at Sun, but it was tough
>slogging.  [ explanation of how to do it deleted ]

>> What we put in the language standard is binding on all implementations. We
>> try to specify things that can be implemented efficiently on any likely
>> system. In addition, we try to specify features so that they have no cost
>> (or nearly no cost) if you don't use them. IMHO, guarantees about what you
>> can do in an asynchronous signal handler don't meet those criteria for
>> inclusion in the C++ standard.
>
>I think I've just described a way to do this that is efficient on any
>likely system, and that has no runtime cost if you don't use it. ...

>An additional stunt is simply to have your exception-handler recognize
>standard function pre and post-ambles, or standard phases of activation
>record construction, and avoid the need for additional code. ...

I'm more than willing to assume your implementation technique has merit.
Yet didn't you say you were not able to get it approved? So what
is a C++ implementor to do if the only reasonable implementation
technique violates the platform ABI?

I have longer experience with non-RISC implementations than with RISC
implementations. It is common for non-RISC implemenations not to have
a recognizable function preamble or postamble. There are not just two or
three possible instruction sequences making up function entry and exit --
there are dozens or even hundreds of possible sequences. If you standardize
on recognizeable entry and exit sequences you take a noticeable performance
hit, particularly on popular benchmark programs.

I want to say again that a criterion for a feature in the standard is not
whether you can somehow implement it on some systems. The criterion is more
like whether you can implement it with appropriate efficiency on all
systems and not adversely affect programs that don't use the feature.
If a feature does not meet this criterion, it has to be widely beneficial
to justify its inclusion.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]