Re: Ada95 to ANSI_C converter

[bobduff@world.std.com (Robert A Duff)]

Jon and Robert: Come on, you guys: be nice!

In article <JSA.97Apr3134856@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>7In article <dewar.860070899@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>> Jon said
>> 
>> <<So, were these tricks still captured in generated C or were they
>> something else?  If they were still captured in the generated C, then
>> it would seem that the use of the term "fundamentally" here is not
>> quite accurate.  I mean, the ICC work would be an existence proof to
>> the contrary.>>

I'm not sure what you're asking.  My belief (from vague memories of a
Dan Eilers post) is that they did something different for different
targets, to support "efficient" trapping of overflows.  I don't know
whether it was different generated C code, or different libraries, or
what.  I've never actually used the thing, myself -- just vague
memories of postings.

Anyway, I think Robert is correct in that machine code (for most
machines) can catch overflows efficiently, whereas ANSI C cannot.
Particular implementations of C might be able to.  So there's something
"fundamental" about this inefficiency, if we're talking about standard,
portable C.

This is just one issue.  How do you implement the "raise" statement in
standard C.  Well, most C programmers return status codes, or whatever,
which is, I think, fundamentally less efficient than real exception
handling supported by a run-time system.  If you're willing to take
advantage of a particular C implementation's stack layout, then you
might be able to gain efficiency.  But in standard C, I don't see how to
implement the typical "near-zero overhead" for entering the region of an
exception handler.

>> No -- read carefully! The ICC work shows you can translate Ada into low
>> level C, and capture 100% of the semantics. This is known, and no one
>> ever contested it. My statement was that such a translation has
>> fundamental efficiency problems. The ICC does not contradict this,
>> rather it demonstrates an instance of these problems. 

I was under the (perhaps mistaken) impression that they used
implementation-dependent tricks to avoid some of those efficiency
problems.

>Robert, you should read a little more carefully.  Please.  The comment
>above is in response to one of Bob's about how the ICC implementation
>_avoided_ inefficiency here.  Now, I don't know for a fact that Bob's
>comment is accurate (that the ICC implementation was _not_ inefficent

I admit that my comment may or may not be accurate.  Sorry.
Maybe Dan Eilers is listening, and can shed light.

>here), but I assumed it was when I asked this question.  So, the
>proper response here should be either:
>
>a) "No, the ICC implementation was actually inefficient here and the
>tricks used did _not_ prevent this problem."
>
>or
>
>b) Address the actual question asked.

Well, I didn't really understand the question, so I'm not surprised
Robert didn't, either.

- Bob