Re: Ada95 to ANSI_C converter

Re: Ada95 to ANSI_C converter

[Nick Roberts]

Jennifer E. Lee <xanadu@ripco.com> wrote in article
<5hbrah$ctt$1@gail.ripco.com>...
> Dear Ada & C gurus:
> 
> We are looking for an "Ada95-to-ANSI_C" converter to run 
> ATS (Abstract Test Suite) via HP Broadband Test System. 
> Can anyone share his or her thoughts on this?
> Thank you in advance.

This raises a few immediate questions. Do you mean ANSI C, or do you mean
ANSI C++ (as it evolves)? Must the converter be able to cope with any Ada
95 source text, or could certain things (such as representation clauses,
for example) be excused?

It would probably be helpful to know about your application in a little
more detail, also.

Essentially, this is a task which should be quite feasible, as long as a
moderately pragmatic approach is taken (IMHO!).

Nick.

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Nick says

<<Essentially, this is a task which should be quite feasible, as long as a
moderately pragmatic approach is taken (IMHO!).>>

Only if you restrict the Ada 95 to a very small subset. There are many
features in Ada 95 that will cause significant trouble in converting to
C (e.g. nested procedures, dynamic aggregates, dynamic arrays, particularly
those in records, variant records, finalization, exceptions, packed arrays,
etc. etc.)

Re: Ada95 to ANSI_C converter

[Jennifer E. Lee]

In article <dewar.859432540@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Nick says
>
><<Essentially, this is a task which should be quite feasible, as long as a
>moderately pragmatic approach is taken (IMHO!).>>
>
>Only if you restrict the Ada 95 to a very small subset. There are many
>features in Ada 95 that will cause significant trouble in converting to
>C (e.g. nested procedures, dynamic aggregates, dynamic arrays, particularly
>those in records, variant records, finalization, exceptions, packed arrays,
>etc. etc.)
>

So it is impossible for such thing like Ada to C converter being made.
Is this what you are suggesting?
--
Love, Jennifer Ellen Lee                              (xanadu@ripco.com)
~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~
I love life, I need food, but I'd rather die without democracy.
 "Ren Min Er Nu:, Shi De Ren Min." -- Wang Dan 1989

Re: Ada95 to ANSI_C converter

[Philip Johnson]

Jennifer E. Lee wrote:
> Our system is an HP Broadband System which only knows C and TTCN.
> Since our project is about the side of 10K to 13K LOC.
> We believe that using an OO language like Ada95 would be a plus
> for us in term of debugging and integration at the testing phase.
> If we want to use C, at least we will look into how to code
> C like an Object-based language like Ada with "PACKAGE" usage.
> However, I really don't know how to do it without using CLASS
> and INHERENT definitions.

Jennifer,

Why not write the application in Ada95 and use the Language interface
to "talk" to the HP Broadband system.  I am using a similar approach
to a data acquisition system now.  I wrote a simple interface package
to converse with the DAS driver dlls and it seems to be working fine.  
This was a proof of concept activity that convinced the customer that
Ada95 was a good choice.  I am now into the main project.


Phil
---- 
 ____________________________________________________________________
|         Ceilidh [Kay Lee] gaelic: A gathering of friends.          |
|                                                                    |
|Philip Johnson                             Telco: (205) 830-9663    |
|Sr. Software Engineer                      email: philipj@hiwaay.net|
|Ceilidh Systems Inc.                                                |
|Madison, AL                                                         |
 --------------------------------------------------------------------

Re: Ada95 to ANSI_C converter

[Craig Franck]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
>
>Jennifer E. Lee <xanadu@ripco.com> wrote in article
><5hbrah$ctt$1@gail.ripco.com>...
>> Dear Ada & C gurus:
>> 
>> We are looking for an "Ada95-to-ANSI_C" converter to run 
>> ATS (Abstract Test Suite) via HP Broadband Test System. 
>> Can anyone share his or her thoughts on this?
>> Thank you in advance.
>
>This raises a few immediate questions. Do you mean ANSI C, or do you mean
>ANSI C++ (as it evolves)? 

Jennifer writes "C gurus", "ANSI_C", and cross-posts to comp.lang.c; 
it is possible she means ANSI C.

>It would probably be helpful to know about your application in a little
>more detail, also.

I always wonder about these language conversion projects myself.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
A fanatic is one who can't change his mind and
won't change the subject -- Winston Churchill

Re: Ada95 to ANSI_C converter

[Jeff Carter]

Jennifer E. Lee wrote:
> We are looking for an "Ada95-to-ANSI_C" converter to run
> ATS (Abstract Test Suite) via HP Broadband Test System.
> Can anyone share his or her thoughts on this?

As many people here will tell you, this is not possible in a general sense.
Ada has features that are not supported by C, such as tasks, generics, and
exceptions, to name a few. For this reason, you cannot buy an Ada to C
translator off the shelf.

If your Ada is restricted to features found in C, then you could write such a
translator, but it is unlikely that you will find an existing one that you can
use.
-- 
Jeff Carter
Innovative Concepts, Inc.

Now go away, or I shall taunt you a second time.

Unsolicited commercial e-mail will be invoiced at US $500 per piece.

Re: Ada95 to ANSI_C converter

[Jennifer E. Lee]

Dear Nick,

Thank you, what I meant is ANSI C now.
Because C is NOT an OO language, and C is only a subset of C++.
We can not convert C++ code back to C.
Our system is an HP Broadband System which only knows C and TTCN.
Since our project is about the side of 10K to 13K LOC.
We believe that using an OO language like Ada95 would be a plus
for us in term of debugging and integration at the testing phase.
If we want to use C, at least we will look into how to code
C like an Object-based language like Ada with "PACKAGE" usage.
However, I really don't know how to do it without using CLASS
and INHERENT definitions.
Could you share your .02$ on this?
Thanks. (A girl is crying for helps :^( ***)
In article <01bc3a3d$7734db20$63f482c1@xhv46.dial.pipex.com>,
Nick Roberts <Nick.Roberts@dial.pipex.com> wrote:
>
>Jennifer E. Lee <xanadu@ripco.com> wrote in article
><5hbrah$ctt$1@gail.ripco.com>...
>> Dear Ada & C gurus:
>> 
>> We are looking for an "Ada95-to-ANSI_C" converter to run 
>> ATS (Abstract Test Suite) via HP Broadband Test System. 
>> Can anyone share his or her thoughts on this?
>> Thank you in advance.
>
>This raises a few immediate questions. Do you mean ANSI C, or do you mean
>ANSI C++ (as it evolves)? Must the converter be able to cope with any Ada
>95 source text, or could certain things (such as representation clauses,
>for example) be excused?
>
>It would probably be helpful to know about your application in a little
>more detail, also.
>
>Essentially, this is a task which should be quite feasible, as long as a
>moderately pragmatic approach is taken (IMHO!).
>
>Nick.
>


--
Love, Jennifer Ellen Lee                              (xanadu@ripco.com)
~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~
I love life, I need food, but I'd rather die without democracy.
 "Ren Min Er Nu:, Shi De Ren Min." -- Wang Dan 1989

Re: Ada95 to ANSI_C converter

[Jennifer E. Lee]

In article <5hcnjf$p50@mtinsc05.worldnet.att.net>,
Craig Franck  <clfranck@worldnet.att.net> wrote:
>"Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
>>
>>Jennifer E. Lee <xanadu@ripco.com> wrote in article
>><5hbrah$ctt$1@gail.ripco.com>...
>>> Dear Ada & C gurus:
>>> 
>>> We are looking for an "Ada95-to-ANSI_C" converter to run 
>>> ATS (Abstract Test Suite) via HP Broadband Test System. 
>>> Can anyone share his or her thoughts on this?
>>> Thank you in advance.
>>
>>This raises a few immediate questions. Do you mean ANSI C, or do you mean
>>ANSI C++ (as it evolves)? 
>
>Jennifer writes "C gurus", "ANSI_C", and cross-posts to comp.lang.c; 
>it is possible she means ANSI C.

Indeed.

>>It would probably be helpful to know about your application in a little
>>more detail, also.
>
>I always wonder about these language conversion projects myself.

C is not even an Object-based language.
Ada95 is an OO language.
Therefore, we use the OO methodology to express in an OO language for
Human, and let the none Human dealing with conversion.
That is the idea.


--
Love, Jennifer Ellen Lee                              (xanadu@ripco.com)
~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~
I love life, I need food, but I'd rather die without democracy.
 "Ren Min Er Nu:, Shi De Ren Min." -- Wang Dan 1989

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Craig says

<<While both your assertions are true, I would point out that the
language cfront had to deal with was less complex than ANSI C++.>>

True, but the author's assumption was that since C++ is OO, and C is
not, the translation is impossible, which is clearly nonsense, and
cfront is a perfectly good proof of this.

In fact the new features added to C++ do not add any fundamental 
difficulties as far as C++ to C translation goes, with the possible
exception of exceptions :-)

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Steve says

<<It's amazing that Ada can be translated to machine code and is so difficult
  to translate to 'C'.  After all 'C' isn't really that much different than
  machine code is it? ;-)>>

Yes, it is not hard to generate completely impossible to read, highly
inefficient C that works.

<<Has anyone done any work to make the GCC back end generate 'C' code?  It
  seems that this might be beneficial
  to all ports that use the GCC back end.>>

The benefit of such a back end would be minimal. It would help a little bit
for bootstrapping GNAT, but that use would not justify the effort, which
would be comparable to doing a new port to a new architecture. I see no
respect in which this would be "beneficial to all ports ...".

No one ever expressed serious interest in such a project, but if they did,
it is certainly something that could be done. Perhaps a person year of
effort would be needed to complete such a project in a reasonably
productized manner. Remember that gcc is MUCH more flexible than C,
so there is no sense in which this would be anything like a direct
translation -- for example if you fed in C, out would come unreadable
rubbish.

The point is that when people ask for Ada to C conversion, they almost
always have in mind a translator that would produce human usable output.
A processor of the kind you suggest seems basically useless to me!

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Craig says

<<It may be impractical. Is there a lot of code to convert, and
will you use this converter for other projects? The simplest
way to convert would be to have one group of Ada programmers
convert the Ada program to a PDL description of the code, along
with constraints and specifications.>>

I doubt that is a helpful suggestion -- PDL is just another programming
language, and there are difficulties in convering from Ada to PDL, and
difficulties in convering from PDL to C. Yes, I know PDL is designed
to ease these difficulties, but in practice, if you are starting with
well written Ada code, I do not think using PDL as an intermediate
step will help, and if you are starting with poorly written Ada code,
then you will probably do better to reengineer in any case.

Re: Ada95 to ANSI_C converter

[Craig Franck]

xanadu@ripco.com (Jennifer E. Lee) wrote:
>
>In article <dewar.859432540@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>>Nick says
>>
>><<Essentially, this is a task which should be quite feasible, as long as a
>>moderately pragmatic approach is taken (IMHO!).>>
>>
>>Only if you restrict the Ada 95 to a very small subset. There are many
>>features in Ada 95 that will cause significant trouble in converting to
>>C (e.g. nested procedures, dynamic aggregates, dynamic arrays, particularly
>>those in records, variant records, finalization, exceptions, packed arrays,
>>etc. etc.)
>>
>
>So it is impossible for such thing like Ada to C converter being made.
>Is this what you are suggesting?

It may be impractical. Is there a lot of code to convert, and
will you use this converter for other projects? The simplest
way to convert would be to have one group of Ada programmers
convert the Ada program to a PDL description of the code, along
with constraints and specifications. Give that to a C group
and let them code it. Run both programs on the same test data
and see if they perfrom to specification. It would difficult
to automate this process; writing the program would take more
time than any one (or several) conversions by hand. Of course,
maybe you will luck out and a product to do this is already
available. Good Luck!

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
A fanatic is one who can't change his mind and
won't change the subject -- Winston Churchill

Re: Ada95 to ANSI_C converter

[Steve Doiel]

In article <dewar.859432540@merv>, dewar@merv.cs.nyu.edu says...
>
>Nick says
>
><<Essentially, this is a task which should be quite feasible, as long as a
>moderately pragmatic approach is taken (IMHO!).>>
>
>Only if you restrict the Ada 95 to a very small subset. There are many
>features in Ada 95 that will cause significant trouble in converting to
>C (e.g. nested procedures, dynamic aggregates, dynamic arrays, particularly
>those in records, variant records, finalization, exceptions, packed arrays,
>etc. etc.)
>

It's amazing that Ada can be translated to machine code and is so difficult
to translate to 'C'.  After all 'C' isn't really that much different than
machine code is it? ;-)

Has anyone done any work to make the GCC back end generate 'C' code?  It
seems that this might be beneficial to all ports that use the GCC back end.

Of course it should not be expected that anyone but a 'C' compiler could
read the generated code.

Just a thought.

Steve Doiel

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Jennifer said

<,Because C is NOT an OO language, and C is only a subset of C++.
We can not convert C++ code back to C.>>

Of course C++ can be translated to C, that's exactly what the original
C++ processor does.

Re: Ada95 to ANSI_C converter

[Craig Franck]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>Jennifer said
>
><,Because C is NOT an OO language, and C is only a subset of C++.
>We can not convert C++ code back to C.>>
>
>Of course C++ can be translated to C, that's exactly what the original
>C++ processor does.
>

While both your assertions are true, I would point out that the
language cfront had to deal with was less complex than ANSI C++.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
A fanatic is one who can't change his mind and
won't change the subject -- Winston Churchill

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <dewar.859526751@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jennifer said
> 
> <,Because C is NOT an OO language, and C is only a subset of C++.
> We can not convert C++ code back to C.>>
> 
> Of course C++ can be translated to C, that's exactly what the original
> C++ processor does.

And, of course Ada can be translated (compiled) to C - isn't that what
the ICC compiler did/does?  It's not as if the original C++ "processor"
generated human readable C.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <5heoel$bc0$1@gail.ripco.com> xanadu@ripco.com (Jennifer E. Lee) writes:

> In article <dewar.859432540@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >Nick says
> >
> ><<Essentially, this is a task which should be quite feasible, as long as a
> >moderately pragmatic approach is taken (IMHO!).>>
> >
> >Only if you restrict the Ada 95 to a very small subset. There are many
> >features in Ada 95 that will cause significant trouble in converting to
> >C (e.g. nested procedures, dynamic aggregates, dynamic arrays, particularly
> >those in records, variant records, finalization, exceptions, packed arrays,
> >etc. etc.)
> >
> 
> So it is impossible for such thing like Ada to C converter being made.
> Is this what you are suggesting?

I think Robert is taking "conversion" to me "translate the Ada95 into
C which is then intended to be read and maintained by humans".  Using
this definition, then his points are relevant.  But, it seems from
what you've said a few times now, that you are really looking for a
"converter" which compiles Ada to C.  Using this definition I believe
Robert would say that, while there may be some issues, this is
certainly doable and may well have been done.  Doesn't ICC sell such a
thing?

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Jon says

<<I think Robert is taking "conversion" to me "translate the Ada95 into
C which is then intended to be read and maintained by humans".  Using
this definition, then his points are relevant.  But, it seems from
what you've said a few times now, that you are really looking for a
"converter" which compiles Ada to C.  Using this definition I believe
Robert would say that, while there may be some issues, this is
certainly doable and may well have been done.>>

Yes, this has been done for Ada 83, and could be done for Ada 95. The
resulting C is fundamentally inefficient, and completely unreadable.

So the question is: what would it be good for, and the answer is as
an intermediate language in some cases, but I can't see man y such
cases.

In virtually all cases, people asking for Ada to C translation are NOT
asking for this kind of approach!

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <dewar.859584395@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon says
> 
> <<I think Robert is taking "conversion" to me "translate the Ada95 into
> C which is then intended to be read and maintained by humans".  Using
> this definition, then his points are relevant.  But, it seems from
> what you've said a few times now, that you are really looking for a
> "converter" which compiles Ada to C.  Using this definition I believe
> Robert would say that, while there may be some issues, this is
> certainly doable and may well have been done.>>
> 
> Yes, this has been done for Ada 83, and could be done for Ada 95. The
> resulting C is fundamentally inefficient, and completely unreadable.

Hmmm, _fundamentally_ inefficient?  I'm not confinced.  Of course, it
definitely will be completely unreadable.


> So the question is: what would it be good for, and the answer is as
> an intermediate language in some cases, but I can't see man y such
> cases.

Well, wasn't it ICC that marketed such a thing for real work?  I'm not
sure they'd agree with you.  In fact, I recall yourself claiming that
there was nothing "fundamentally" wrong with the approach.


> In virtually all cases, people asking for Ada to C translation are NOT
> asking for this kind of approach!

Perhaps.  But that is irrelevant.  The specific case is whether
Jennifer wants this approach, and it's unclear why people should
presume what it is she really wants and then trash her for it.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[David Emery]

>This raises a few immediate questions. Do you mean ANSI C, or do you mean
>ANSI C++ (as it evolves)? 

Note that C++ is entering ballot as both an ANSI and ISO standard.
That means we should finally have a C++ standard by the end of the year,
2 1/2 years after the Ada95 standard!  

			dave
-- 
Note: if email to me bounces, use 'emery@grebyn.com'

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Jon says (of translating Ada to C)

<<Hmmm, _fundamentally_ inefficient?  I'm not confinced.  Of course, it
definitely will be completely unreadable.>>

OK, tell me how you intend, in ANSI C, to handle finalization and 
exceptions, or integer overflow checking, or .... If you are not
confinced of the problem, I would guess you have not looked into
it closely. 

Now of course the inefficiency may be acceptable, but there is no question
that there are fundamental inefficiencies in this approach.

<<Perhaps.  But that is irrelevant.  The specific case is whether      
Jennifer wants this approach, and it's unclear why people should     
presume what it is she really wants and then trash her for it.       
>>

Well I am not sure what you mean by "trash" here, I didn't see any
such messages. I did see messages that assumed she was looking for
readable C. The reason is that it is relatively hard to imagine
a scenario for her questions that does not need readable C, but
we can let her speak for herself.

Re: Ada95 to ANSI_C converter

[Robert A Duff]

In article <JSA.97Mar31144058@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>Hmmm, _fundamentally_ inefficient?  I'm not confinced.  Of course, it
>definitely will be completely unreadable.

Robert is probably alluding to the fact that C doesn't catch overflows.
Of course, one could imagine a translator that assumed the Ada program
isn't bothered by overflows...

>Well, wasn't it ICC that marketed such a thing for real work?  I'm not
>sure they'd agree with you.  In fact, I recall yourself claiming that
>there was nothing "fundamentally" wrong with the approach.

I believe ICC used various implementation-dependent tricks to catch
overflows efficiently.  And they didn't claim to produce readable C --
just correct C.

>Perhaps.  But that is irrelevant.  The specific case is whether
>Jennifer wants this approach, and it's unclear why people should
>presume what it is she really wants and then trash her for it.

Indeed.  IMHO, the correct response to the common "does there exist a
translator from language X to language Y?" question should be some
questions: Do you want any or all of (1) completely correct
implementation of language X?, (2) Do you want the generated code to be
fast?, and (3) Do you want it to be readable to regular language-Y
folks?  Perhaps also, (4) do you want the typical language-Y debugger to
make sense of it?

I have witnessed successful semi-automated translations from one
language to another, even when readability was important.  IMHO, it
helps if (1) the translator can take advantage of the idioms used by a
particular program in the source language (e.g. we don't care about
overflow, or we don't use nested procedures), (2) the source language is
higher level than the target, (3) one is willing to fiddle with the
source code, to make the target code come out reasonable, and (4) one is
willing to fiddle with the target code, after having gotten it to
"work".

Translating from good C to good Ada is nigh unto impossible.
Translating in the other direction is perhaps doable (although it tends
to cost approx the same as an Ada compiler, which is, these days, into
millions of dollars).

- Bob

Re: Ada95 to ANSI_C converter

[David Kristola]

In article 1@gail.ripco.com, xanadu@ripco.com (Jennifer E. Lee) writes:
>Dear Nick,
>
>Thank you, what I meant is ANSI C now.
>Because C is NOT an OO language, and C is only a subset of C++.
>We can not convert C++ code back to C.
>Our system is an HP Broadband System which only knows C and TTCN.
>Since our project is about the side of 10K to 13K LOC.
>We believe that using an OO language like Ada95 would be a plus
>for us in term of debugging and integration at the testing phase.
>If we want to use C, at least we will look into how to code
>C like an Object-based language like Ada with "PACKAGE" usage.
>However, I really don't know how to do it without using CLASS
>and INHERENT definitions.
>Could you share your .02$ on this?
>Thanks. (A girl is crying for helps :^( ***)

Might you be able to get an Ada compiler for your HP Broadband System?
I was (pleasantly) surprised the other day when i learned that the C
compiler that came with some embedded stuff we are using was actually
GCC.  If there is a GCC back end for your target, then a GNAT cross
compiler should be possible.  I am sure the folks at ACT would be glad
to help (for a fee).  HP might even be interested in seeing an Ada
compiler for this system.


--david kristola (not speaking for Lockheed Martin or SAMCO)
Home: David95037 at aol dot com
Work: davidk at os6 dot epc dot lmms dot lmco dot com
Spam: eat-spam-and-die@dev.null

Re: Ada95 to ANSI_C converter

[Jennifer E. Lee]

Philip Johnson  <philipj@hiwaay.net> wrote:
>Jennifer E. Lee wrote:
>> Our system is an HP Broadband System which only knows C and TTCN.
>> Since our project is about the side of 10K to 13K LOC.
>> We believe that using an OO language like Ada95 would be a plus
>> for us in term of debugging and integration at the testing phase.
>> If we want to use C, at least we will look into how to code
>> C like an Object-based language like Ada with "PACKAGE" usage.
>> However, I really don't know how to do it without using CLASS
>> and INHERENT definitions.
>
>Jennifer,
>
>Why not write the application in Ada95 and use the Language interface
>to "talk" to the HP Broadband system.  I am using a similar approach
>to a data acquisition system now.  I wrote a simple interface package
>to converse with the DAS driver dlls and it seems to be working fine.  
>This was a proof of concept activity that convinced the customer that
>Ada95 was a good choice.  I am now into the main project.
>
>

Phil,

Thank you, but how?
The HP Broadband Systems (HPBS) only recognizes ANSI C and TTCN 
(Tree & Tabular Combined Notation) object codes.
Our clients want us to integrate their Ada95 OO code with our C codes 
which is almost impossible IMHO because C is not an OO language.
How do we convert Ada's _package_, TEXT_IO, .... to HP's C function?
The HPBS is a validation device for us to emulate our clients'
SDH/SONNET/ATM networks.

My idea is, 

Ada95_to_ANSIC 
BEGIN
        IF case I := Ada to C conversion not gonna to work;
                THEN we have recode our client's OO Ada code to C;

        ELSE case II := there is an Ada to C convertor;
                THEN we let the converter to fix the conversion problem;
END
  
OK, another question. 
How do you use C to code like an OO Ada program?
Thank you in advance.
      
--
Love, Jennifer Ellen Lee                              (xanadu@ripco.com)
~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~
I love life, I need food, but I'd rather die without democracy.
 "Ren Min Er Nu:, Shi De Ren Min." -- Wang Dan 1989

Re: Ada95 to ANSI_C converter

[Jennifer E. Lee]

David Kristola <davidk@OS7.ifs> wrote:
>Might you be able to get an Ada compiler for your HP Broadband System?

No, HP only makes C and TTCN compilers for their systems.
HP Broadband is a device which we can emulate our client's networks.

>I was (pleasantly) surprised the other day when i learned that the C
>compiler that came with some embedded stuff we are using was actually
>GCC.  If there is a GCC back end for your target, then a GNAT cross
>compiler should be possible.  I am sure the folks at ACT would be glad
>to help (for a fee).  HP might even be interested in seeing an Ada
>compiler for this system.

Do you have their numbers or emails of ACT?
--
Love, Jennifer Ellen Lee                              (xanadu@ripco.com)
~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~
I love life, I need food, but I'd rather die without democracy.
 "Ren Min Er Nu:, Shi De Ren Min." -- Wang Dan 1989

Re: Ada95 to ANSI_C converter

[Tom Wheeley]

In article <5henq6$b3m$1@gail.ripco.com>
           xanadu@ripco.com "Jennifer E. Lee" writes:

> Dear Nick,
> 
> Thank you, what I meant is ANSI C now.
> Because C is NOT an OO language, and C is only a subset of C++.
> We can not convert C++ code back to C.

Oh yes you can.  That's how the `cfront' C++ compiler works.

And strictly, C is not a subset of C++.  C has many (often esoteric) features
which are not in C++.  Not to mention a//**/b
;

-- 
:sb)

Re: Ada95 to ANSI_C converter

[Robert I. Eachus]

In article <5hrh21$2k$1@gail.ripco.com> xanadu@ripco.com (Jennifer E. Lee) writes:

 > The HP Broadband Systems (HPBS) only recognizes ANSI C and TTCN 
 > (Tree & Tabular Combined Notation) object codes.
 > Our clients want us to integrate their Ada95 OO code with our C codes 
 > which is almost impossible IMHO because C is not an OO language.
 > How do we convert Ada's _package_, TEXT_IO, .... to HP's C function?
 > The HPBS is a validation device for us to emulate our clients'
 > SDH/SONNET/ATM networks.

  Have you looked at Annex B?  It looks to me as if what you are
trying to do here is interface to a low-level comm package.  Get the
Intermetrics C to Ada converter for the header files or just convert
by hand, then build whatever higher level glue code you may need in
Ada.

  But it sounds like what you really want is for HP or ACT (email to
sales@gnat.com) to support the Ada distributed systems annex on top of
HPBS.  This would allow you to write completely in Ada and leave the
low level marshalling and unmarshalling of data to the distribution
the provided code.

  Of course you could just get the source and modify it yourself, but
I get the impression that this is not something you want to do.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada95 to ANSI_C converter

[Philip E. Johnson]

Jennifer E. Lee wrote:
[deleted stuff]
> The HP Broadband Systems (HPBS) only recognizes ANSI C and TTCN
> (Tree & Tabular Combined Notation) object codes.
> Our clients want us to integrate their Ada95 OO code with our C codes
> which is almost impossible IMHO because C is not an OO language.
> How do we convert Ada's _package_, TEXT_IO, .... to HP's C function?
[deleted stuff]
> OK, another question.
> How do you use C to code like an OO Ada program?

for the real time DAS I mentioned:

All of my application code is written in Ada95.  I use the language
pragma to interface my Ada95 code to system level C/C++ dlls.  The 
system level dlls provide the communication pipeline to the system 
hardware [I am running on WindowsNT and cannot touch hardware direct].

If your C code is high level application code [not system drivers] then
it is a different problem.  If the customer's Ada95 OO code [caveat:
It can be written in Ada95 and not be OO] resolves into a lower level
[system level] message passing to the system then it may require only an
interface between Ada and C.  If the C code is high level application
code
then the interface will probably be more complex.  This would require a 
closer examination of both the Ada95 and C codes 

Phil
----
 ____________________________________________________________________
|                                                                    |
|          Ceilidh [Kay Lee] gaelic: A gathering of friends          |
|                                                                    |
|Philip Johnson                             Telco: (205) 830-9663    |
|Sr. Software Engineer                      email:philipj@HIWAAY.net |
|Ceilidh Systems Inc.                                                |
|Madison, AL                                                         |
 --------------------------------------------------------------------

Re: Ada95 to ANSI_C converter

[Richard Kenner]

In article <5hfble$4d0$1@news.pacifier.com> steved@pacifier.com (Steve Doiel) writes:
>Has anyone done any work to make the GCC back end generate 'C' code?  It
>seems that this might be beneficial to all ports that use the GCC back end.

No one has done this and I don't think this would be all that useful.
When you consider that many front ends (specifically that for Ada) use
features that aren't expressable in C (most notably discriminated
records), that C that would have to be produced would correspond a lot
more to an *interpreter* of the program than a compilation of it.

It might be an interesting exercise to do something like this, but I
don't think it would be as beneficial as you think.

Re: Ada95 to ANSI_C converter

[Richard Kenner]

In article <dewar.859559977@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>No one ever expressed serious interest in such a project, but if they did,
>it is certainly something that could be done. Perhaps a person year of
>effort would be needed to complete such a project in a reasonably
>productized manner.

I think that's a bit of an overestimate, but could be true for people who
aren't that familiar with GCC.

Everyone should realize, however, that we're talking about generating
"C" code like:

	r10=r7+r30;
	r72=r8*r9;
	r3=r6+72;
	r28=memory[r3];

....

Re: Ada95 to ANSI_C converter

[Richard Kenner]

In article <dewar.859987799@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>The discrepancy here has to do with your view of what it means to produce
>something like this. If you are talking about just getting something
>working, and someone who knows GCC is doing the work, you can cranck 
>something out pretty quick. But to make something approach a usable product
>is always much more work
>
>One thing that would complicate this particular project substantially is
>the testing. Since the idea is to get something that works on all C compilers
>on all machines, reasonably thorough testing means playing on lots of
>different machines, which always adds a lot of effort.

Yes, I was indeed referring to just getting something working.  It's
not too clear what making a "product" out of such a thing would mean,
especially because of the testing issues you raise, which would be a
major proposition.

I'd view such an effort as creating more of a *tool* that could be used
in various products than as a product itself.

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Richard said

<<I think that's a bit of an overestimate, but could be true for people who
aren't that familiar with GCC.>>

This was in reference to my guess of a person year for doing a C generating
gcc backend.

The discrepancy here has to do with your view of what it means to produce
something like this. If you are talking about just getting something
working, and someone who knows GCC is doing the work, you can cranck 
something out pretty quick (Richard did the first stage of work on the
Alpha port in about a month, including learning the architecture) ...

But to make something approach a usable product is always much more work
(as Richard also knows well if he puts his ACT hat on :-) 

One thing that would complicate this particular project substantially is
the testing. Since the idea is to get something that works on all C compilers
on all machines, reasonably thorough testing means playing on lots of
different machines, which always adds a lot of effort.

Re: Ada95 to ANSI_C converter

[Robert A Duff]

In article <dewar.859987799@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>One thing that would complicate this particular project substantially is
>the testing. Since the idea is to get something that works on all C compilers
>on all machines, reasonably thorough testing means playing on lots of
>different machines, which always adds a lot of effort.

I suspect you'd spend most of your time working around bugs and
limitations in various C compilers, given that the output of this tool
would be C written in an "unusual" style, and thus not well exercised in
C compilers.

- Bob

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Richard said

<<I'd view such an effort as creating more of a *tool* that could be used
in various products than as a product itself.>>

Right, that's certainly a reasonable view. One interesting bit of history
here is that at one point in GNAT project we talked about making a backend
that generated the kind of junk C that Richard quoted in his previous
message. The idea was to provide a bootstrap path for systems that lack
GNAT now -- in this scenario, we would distribute the junk c, and people
could compile it on some such system.

However, in practice, the cross-compilation approach has worked very well,
a combination of the basic technology of gcc being strong in this area,
and the internet at work (somewhere, it is likely that there is someone
interested in porting GNAT to machine A, who has access to machine B for
which a GNAT already exists). 

The original ancestor of GNAT for those interested was a SunOS implementation
on Sparc that was bootstrapped using the Alsys Ada 83 compiler. As soon as
that was successfully bootstrapped, the Alsys compiler was permanently 
retired, and all subsequent GNAT implementations for SunOS and all other
systems can trace their heritage to this original bootstrap.

GNAT is on a lot of machines and systems now, and we have the impression
that the requirement to use the cross-compilation path has not been an
impediment. Everynow and then, we get someone who naively acquires the
sources, puts them on a machine with no GNAT, and expects to be able to
build GNAT -- not such a surprising mistake, since this approach will work
for pretty much all other GNU software which is written in C.

At first, we felt it was important to make this true of GNAT now, but as I
say, it seems from experience like this is not a critical issue. I really
can't think of a single case of a machine for which GNAT does not exist,
and would exist if it could be moved in this manner. Sure there are machines
for which GNAT does not exist (even a few for which GCC does not exist), but
the cross-compilation does not seem to be the barrier in such cases.

Robert Dewar

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <E7xots.51o@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> Jon S Anthony <jsa@alexandria> wrote:
> >Hmmm, _fundamentally_ inefficient?  I'm not confinced.  Of course, it
> >definitely will be completely unreadable.
> 
> Robert is probably alluding to the fact that C doesn't catch overflows.
> Of course, one could imagine a translator that assumed the Ada program
> isn't bothered by overflows...

OK, that makes sense.


> I believe ICC used various implementation-dependent tricks to catch
> overflows efficiently.  And they didn't claim to produce readable C --
> just correct C.

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.


> >Perhaps.  But that is irrelevant.  The specific case is whether
> >Jennifer wants this approach, and it's unclear why people should
> >presume what it is she really wants and then trash her for it.
> 
> Indeed.  IMHO, the correct response to the common "does there exist a
> translator from language X to language Y?" question should be some
> questions: Do you want any or all of (1) completely correct
> implementation of language X?, (2) Do you want the generated code to be
> fast?, and (3) Do you want it to be readable to regular language-Y
> folks?  Perhaps also, (4) do you want the typical language-Y debugger to
> make sense of it?

Excellent points.  This really makes sense to me.


> I have witnessed successful semi-automated translations from one
> language to another, even when readability was important.  IMHO, it
> helps if (1) the translator can take advantage of the idioms used by a
> particular program in the source language (e.g. we don't care about
> overflow, or we don't use nested procedures), (2) the source language is
> higher level than the target, (3) one is willing to fiddle with the
> source code, to make the target code come out reasonable, and (4) one is
> willing to fiddle with the target code, after having gotten it to
> "work".

Agree on all points.  One example of this (all points 1-4) that I know
of concerned translating Lisp to C - where the intent was readable
result.  The old Chestnut translator for this (particularly if you
were willing to go with 3) IMO produced truely great results.  In
general I would say the generated C was far better than most hand
crafted C I have seen.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Fergus Henderson]

kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

>In article <5hfble$4d0$1@news.pacifier.com> steved@pacifier.com (Steve Doiel) writes:
>>Has anyone done any work to make the GCC back end generate 'C' code?  It
>>seems that this might be beneficial to all ports that use the GCC back end.
>
>No one has done this and I don't think this would be all that useful.
>When you consider that many front ends (specifically that for Ada) use
>features that aren't expressable in C (most notably discriminated
>records), that C that would have to be produced would correspond a lot
>more to an *interpreter* of the program than a compilation of it.

But there has been some work done on making gcc compile to a
machine-independent(?) bytecode, hasn't there?
There is some bytecode stuff in the gcc source code,
but from the looks of things, it isn't complete yet.

A gcc->bytecode compiler and a bytecode interpreter would suffice
for bootstrapping purposes,

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Ada95 to ANSI_C converter

[Jennifer E. Lee]

Jon S Anthony <jsa@alexandria> wrote:
>I'm not Phil, but I am now getting the drift of what you are up
>against.  Let me recap to see if at least the problem is now "clear":
>
>  1. HPBS apparently only has a C compiler targetting it.

CORRECT.

>  2. There is (apparently) no way to communicate with the HPBS from
>     another subsystem (which could have a board or some such which
>     does have something more than a C compiler - in particular an
>     Ada95 compiler.)

No, it doesn't. HPBS is an off the shelf validation device which can
emulate our client's SDH/SONNET/ATM network. Our client do not want
us to integrate our codes with their network system softwares.

>  3. Whatever it is that needs to be accomplished, the end result must
>     _run_ on the HPBS (probably because of 2 or 2 plus some other
>     reasons).

Indeed. That's called "INFORMATION HIDING." They want us to validate
their Ada codes through our HPBS.

>It sounds as if 1. is definitely true at the moment.  Is 2 really
>true?  I find this somewhat hard to believe (as a variety of control
>systems that I am aware of support this sort of thing).  If 2. really
>is true then 3. would seem to follow automatically.
>
>Now, if 2. is true (and thus 3), Ada.Interfaces is not going to help
>you and Phil's suggestion is, unfortunately, not viable.

You are right. Please notice, the we have to use HP's C function
library to call up the HPBS' manager program.

>If 2. is _not_ true, then the "other subsystem which can communicate
>to the HPBS" must have a library supplied for it which allows this
>communication (this is standard for the sort of control systems I
>mentioned above).  Presumably
>
>a) this library's source would be in C, as you folks would be the ones
>supplying it for your product!

Again, a good understanding of my question.

>b) your customer's Ada95 code is running on this thing (which implies
>that it _does_ have an Ada95 compiler for it) as why else would they
>believe that they could even use your product.

No, their Ada codes are for their network system applications only.
However, they need to send cell through the ATM/SONNET networks via
our BOX (can not tell you the name; it's a MUX.)

>If a) and b) are true, then you are in luck and Phil's suggestion will
>work like a charm.  Just use Ada.Interfaces to write an abstracted
>interface to your library.  There is no problem in having OO Ada95
>call out to your non-OO C.  Works fine.

a.) is true, bur b.) is not.

>Going back to the case of 2. being true (and thus a) and b) are
>irrelevant), then we come to the following sort of possibilities:
>
>  I.  Get some Ada95 to C compiler whose output will compile under the
>      C compiler you have for the HPBS.  Maybe ICC's will work.
>
>  II. Get someone (Aonix or ACT) to provide an Ada95 cross compiler to
>      the HPBS (effectively giving the HPBS an Ada95 compiler).

No, we want an Ada cross complier which can embeded c function in it.

>The other possibility (which you mention) of recoding the Ada95 into C
>is, IMO, much more expensive than either I or II and _far_ more risky.

Indeed.

>Am I now correctly understanding the situation???

Very much, thank you. :^)
--
Love, Jennifer Ellen Lee                              (xanadu@ripco.com)
~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~@>*---~
I love life, I need food, but I'd rather die without democracy.
 "Ren Min Er Nu:, Shi De Ren Min." -- Wang Dan 1989

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <5hrh21$2k$1@gail.ripco.com> xanadu@ripco.com (Jennifer E. Lee) writes:

> Philip Johnson  <philipj@hiwaay.net> wrote:
> >Jennifer,
> >
> >Why not write the application in Ada95 and use the Language interface
> >to "talk" to the HP Broadband system.  I am using a similar approach
> >to a data acquisition system now.  I wrote a simple interface package
> >to converse with the DAS driver dlls and it seems to be working fine.  
> >This was a proof of concept activity that convinced the customer that
> >Ada95 was a good choice.  I am now into the main project.
...[snip]...
> Thank you, but how?
> The HP Broadband Systems (HPBS) only recognizes ANSI C and TTCN 
> (Tree & Tabular Combined Notation) object codes.
> Our clients want us to integrate their Ada95 OO code with our C codes 
> which is almost impossible IMHO because C is not an OO language.
> How do we convert Ada's _package_, TEXT_IO, .... to HP's C function?
> The HPBS is a validation device for us to emulate our clients'
> SDH/SONNET/ATM networks.

I'm not Phil, but I am now getting the drift of what you are up
against.  Let me recap to see if at least the problem is now "clear":

  1. HPBS apparently only has a C compiler targetting it.

  2. There is (apparently) no way to communicate with the HPBS from
     another subsystem (which could have a board or some such which
     does have something more than a C compiler - in particular an
     Ada95 compiler.)

  3. Whatever it is that needs to be accomplished, the end result must
     _run_ on the HPBS (probably because of 2 or 2 plus some other
     reasons).

It sounds as if 1. is definitely true at the moment.  Is 2 really
true?  I find this somewhat hard to believe (as a variety of control
systems that I am aware of support this sort of thing).  If 2. really
is true then 3. would seem to follow automatically.

Now, if 2. is true (and thus 3), Ada.Interfaces is not going to help
you and Phil's suggestion is, unfortunately, not viable.

If 2. is _not_ true, then the "other subsystem which can communicate
to the HPBS" must have a library supplied for it which allows this
communication (this is standard for the sort of control systems I
mentioned above).  Presumably

a) this library's source would be in C, as you folks would be the ones
supplying it for your product!

b) your customer's Ada95 code is running on this thing (which implies
that it _does_ have an Ada95 compiler for it) as why else would they
believe that they could even use your product.

If a) and b) are true, then you are in luck and Phil's suggestion will
work like a charm.  Just use Ada.Interfaces to write an abstracted
interface to your library.  There is no problem in having OO Ada95
call out to your non-OO C.  Works fine.

Going back to the case of 2. being true (and thus a) and b) are
irrelevant), then we come to the following sort of possibilities:

  I.  Get some Ada95 to C compiler whose output will compile under the
      C compiler you have for the HPBS.  Maybe ICC's will work.

  II. Get someone (Aonix or ACT) to provide an Ada95 cross compiler to
      the HPBS (effectively giving the HPBS an Ada95 compiler).

The other possibility (which you mention) of recoding the Ada95 into C
is, IMO, much more expensive than either I or II and _far_ more risky.

Am I now correctly understanding the situation???

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Robert Dewar]

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.>>


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. 

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <5hvjb7$7us$1@gail.ripco.com> xanadu@ripco.com (Jennifer E. Lee) writes:

> Jon S Anthony <jsa@alexandria> wrote:
> >  1. HPBS apparently only has a C compiler targetting it.
>
> CORRECT.
>
> >  2. There is (apparently) no way to communicate with the HPBS from
> >     another subsystem (which could have a board or some such which
> >     does have something more than a C compiler - in particular an
> >     Ada95 compiler.)
>
> No, it doesn't. HPBS is an off the shelf validation device which can
> emulate our client's SDH/SONNET/ATM network. Our client do not want
> us to integrate our codes with their network system softwares.

OK - that's some new information.


> >  3. Whatever it is that needs to be accomplished, the end result must
> >     _run_ on the HPBS (probably because of 2 or 2 plus some other
> >     reasons).
>
> Indeed. That's called "INFORMATION HIDING." They want us to validate
> their Ada codes through our HPBS.

OK, it sounds as if the important part here is that everything has to
run on the HPBS.  In particular, the customer's code.


> You are right. Please notice, the we have to use HP's C function
> library to call up the HPBS' manager program.

Sure, but that in itself is not a problem.  It's a problem if BOTH

i. It only lives on HPBS (I'm sure you are saying this is true)
and
ii. You can't talk to the HPBS from another box

Is ii. true???  If not (that is you _can_ talk to the HPBS from
another box), then you may yet be in luck.


> >a) this library's source would be in C, as you folks would be the ones
> >supplying it for your product!
>
> Again, a good understanding of my question.

But, I think you are saying this library also only lives on HPBS.
Correct?


> >b) your customer's Ada95 code is running on this thing (which implies
> >that it _does_ have an Ada95 compiler for it) as why else would they
> >believe that they could even use your product.
>
> No, their Ada codes are for their network system applications only.
> However, they need to send cell through the ATM/SONNET networks via
> our BOX (can not tell you the name; it's a MUX.)

So the picture is:

  +------------------+
  |  Box Running     |
  |  Client Ada95    |
  |  network system  |======> Normally hooked to SDH/ATM/SONNET network
  |  application     |	      (presumably this box has drivers for this
  |  code            |	       network "card")
  |                  |
  +------------------+

For testing you want to have:

  +------------------+	      +------------------+
  |  Box Running     |	      |  Your Box (based |
  |  Client Ada95    |	      |  on HPBS)      	 |
  |  network system  |	      |  emulating the   |
  |  application     |=======>|  SDH/ATM/SONNET  |
  |  code            |        |  network         |
  |                  |        |                  |
  +------------------+        +------------------+

Or do you really want:

  +----------------------------------------+
  |  Your Box (based on HPBS) running BOTH |
  |  your emulation code for ATM/SONNET    |
  |    AND				   |
  |  Client Ada95     			   |
  |  network system   			   |
  |  application      			   |
  |  code             			   |
  +----------------------------------------+

Which of these last two pictures is accurate for your situation??


> >  I.  Get some Ada95 to C compiler whose output will compile under the
> >      C compiler you have for the HPBS.  Maybe ICC's will work.
> >
> >  II. Get someone (Aonix or ACT) to provide an Ada95 cross compiler to
> >      the HPBS (effectively giving the HPBS an Ada95 compiler).
>
> No, we want an Ada cross complier which can embeded c function in it.

Yes, but that is just out of the box Ada95 so if you have your cross
compiler you are done.  The linker will take care of the rest.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

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.>>
> 
> 
> 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. 

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
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.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[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

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Bob said

<<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.
>>

The implementation tricks that Bob refers to can alleviate some of the
cost of overflow checking, but by no means all, on any architecture
that I can imagine. One can always of course build a C compiler that
specifically recognizes "overflow patterns", and reliably generate
optimal code with the check -- I know of no such C compiler.

I will make the statement once more, unconditionally and clearly: The
decision to generate C, rather than object code directly, involves
a number of fundamental inefficiencies, one of which is overflow checking!

I have not seen anything that contests this position!

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Jon said

<<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
here), but I assumed it was when I asked this question.  So, the
proper response here should be either:>>

Nope, that's not what Bob said, he said that ICC used some implementation
dependent tricks -- that's true! Not that they avoided inefficiencies.
Reread Bob's post, you will see that you invented the word avoid (you
just read that into it, but it is not what he said!!)

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <E831sB.M4s@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> >> <<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.

OK, this is certainly an answer to the question - you aren't sure how
the tricks were done.  Basically I just was wondering if the "tricks"
were implemented via generated C (then assuming they really were
efficient, then the ICC impl would be something of a counter example -
at least for overflow stuff).


> Particular implementations of C might be able to.  So there's something
> "fundamental" about this inefficiency, if we're talking about standard,
> portable C.                                                   ^^^^^^^^
  ^^^^^^^^^^

OK, check.


> 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.

OK, you convinced me.


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

Managed to answer it though! :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Howard W. LUDWIG]

David Emery wrote:
> 
> >This raises a few immediate questions. Do you mean ANSI C, or do you mean
> >ANSI C++ (as it evolves)?
> 
> Note that C++ is entering ballot as both an ANSI and ISO standard.
> That means we should finally have a C++ standard by the end of the year,
> 2 1/2 years after the Ada95 standard!
> 
>                         dave

C++ is presently going through balloting of the Committee Draft #2 and last
month finished the public comment period on the draft.  The various comments
(public and ballot) will need to be addressed.  Then the Draft International
Standard will be submitted for balloting (presently anticipated January 1998).
The publication of the ISO standard is not expected until around August 1998,
about 3 1/2 years after the Ada 95 standard, so Dave was overly optimistic
for C++ by about a year.

Howard W. LUDWIG, Ph.D.
Working, but not speaking, for Lockheed Martin Electronics & Missiles Co.

Re: Ada95 to ANSI_C converter

[Keith Thompson]

In <E80s46.H1D@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
> In article <dewar.859987799@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >One thing that would complicate this particular project substantially is
> >the testing. Since the idea is to get something that works on all C compilers
> >on all machines, reasonably thorough testing means playing on lots of
> >different machines, which always adds a lot of effort.
> 
> I suspect you'd spend most of your time working around bugs and
> limitations in various C compilers, given that the output of this tool
> would be C written in an "unusual" style, and thus not well exercised in
> C compilers.

Which suggests that this could be an interesting way to generate nasty
test cases for C compilers.  I wonder how hard it would be to do the
same kind of thing for Ada compilers.

(I *like* nasty test cases.)

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
5040 Shoreham Place, San Diego, CA, USA, 92122-5989
"Humor is such a subjective thing." -- Cartagia

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Keith says

<<(I *like* nasty test cases)>>

The trouble with nasty test cases is that they can sometimes result in
implementors wasting huge amounts of time getting things right that are
of no possible concern to users. The old ACVC suite was full of such
things, and it is still quite often the case that we make a change
and it affects none of our user programs in our regression suite, but
it causes an obscure bug in some ACVC test. Equally, it is often the
case that a change blows away huge numbers of user tests, but the
ACVC hums merrily on with no errors. 

Anecdotally (we really should collect data on this, we have the raw data),
we have the impression that the Ada 95 tests tend to track user programs
more closely. They are certainly much less full of "nasty test cases".

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <dewar.860114168@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon said
> 
> <<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
> here), but I assumed it was when I asked this question.  So, the
> proper response here should be either:>>
> 
> Nope, that's not what Bob said, he said that ICC used some implementation
> dependent tricks -- that's true! Not that they avoided inefficiencies.
> Reread Bob's post, you will see that you invented the word avoid (you
> just read that into it, but it is not what he said!!)

From DejaNews:

--------------
Subject:      Re: Ada95 to ANSI_C converter
From:         bobduff@world.std.com (Robert A Duff)
Date:         1997/04/01
Message-Id:   <E7xots.51o@world.std.com>
Newsgroups:   comp.lang.ada,comp.lang.c
[More Headers]

In article <JSA.97Mar31144058@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>Hmmm, _fundamentally_ inefficient?  I'm not confinced.  Of course, it
>definitely will be completely unreadable.

Robert is probably alluding to the fact that C doesn't catch overflows.
Of course, one could imagine a translator that assumed the Ada program
isn't bothered by overflows...

>Well, wasn't it ICC that marketed such a thing for real work?  I'm not
>sure they'd agree with you.  In fact, I recall yourself claiming that
>there was nothing "fundamentally" wrong with the approach.

I believe ICC used various implementation-dependent tricks to catch
overflows efficiently.  And they didn't claim to produce readable C --
*********************
          ***********
just correct C.

-------------------------

Emphasis mine.  I read "to catch overflows efficiently" as being
interchangeable with "to avoid inefficiencies in catching overflows".
I think Bob has already agreed with this, but that he meant to also
say he didn't really know for sure if it worked.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Jon says

<<Emphasis mine.  I read "to catch overflows efficiently" as being
interchangeable with "to avoid inefficiencies in catching overflows".
I think Bob has already agreed with this, but that he meant to also
say he didn't really know for sure if it worked.>>

Well there is efficiency and efficiency, Bob Duff was cerrtainly not
saying that the ICC compiler avoided inefficiencies in catching
overflows, just that they tried to be efficient in handling overflow,
rather different issues.

If Bob DID mean to imply that ICC avoided all efficiency penalties
in handling overflows in C generated code, that's just plain wrong!

So, let's not obscure the semantics here.

Generating C invoves fundamental inefficiencies in a number of areas,
including catching overflows. That's the important point to register
here. Yes, you can try to catch overflow efficiently, but you cannot
avoid fundamental inefficiencies in the result. As I say, we know this
area VERY well, because we are beginning to play more of these efficiency
tricks in catching overflow in GNAT -- that will indeed improve
efficiency, but it will NOT avoid all inefficiencies.

The bottom line here is that there is a significant efficiency penalty
in generating C, and it cannot be eliminated, no matter how clever you are!

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Jon said

<<Emphasis mine.  I read "to catch overflows efficiently" as being
interchangeable with "to avoid inefficiencies in catching overflows".
I think Bob has already agreed with this, but that he meant to also
say he didn't really know for sure if it worked.>>

incidentally I definitely see how you could read Bob's statement the
way you did, rereading it. I guess the reason I did not read it that
way was because I knew that would be a completely false implication,
and I assumed, perhaps too charitably, that no one would make the 
claim that it would be possible to eliminate the penalty for overflow
checking when generating C :-)

You on the other hand, I guess really wanted it to be possible to 
generate efficient C, so you were happy to read it more optimistically.
Just goes to show that it is not easy to be 100% clear in email!

Re: Ada95 to ANSI_C converter

[Peter Seebach]

In article <334929E8.4E68@gdls.com>, Arthur Schwarz  <schwarza@gdls.com> wrote:
>Well, they *would* be better drivers.

Better car mechanics, perhaps.  Better drivers than people who spent the same
amount of time studying driving?  I doubt it.

>In any case, the analogy is not valid, because we are not training
>users of computers, which obviously do not (or should not, at least)
>need to understand programming.  We are training programmers, and
>thus they should learn the fundamentals of programming.

Define fundementals.

To be an effective programmer, do I need to know the physics behind an
XOR-gate?  Do I need to know how exactly it is that electrons can repel each
other?  Do I need to know how my computer's CPU has implemented addition in
terms of smaller gates?  Do I need to know the algorithms used for the cache?
Do I need to know what patters of pulses are used to communicate with main
memory?

What is so magical about "assembly" that makes it the right level?  My
experience has been that C is often a bit lower level than I really want to be
thinking, and can obscure important design issues with implementation trivia.

>Or do you think automotive engineers should not understand the
>physics of motors and motion, and should only work with prefabricated
>components?

Oh, such as standardized screws and bolts?  What a horrible thing those are.

What "the basics" are can vary significantly depending on target application.
For most modern programmers, especially those learning today, the relative
simplicity of an abstract machine is probably closer to the problem domain,
and really won't hurt performance... By contrast, obsession with trivial
details can and will lead to unportable, inefficient code.

I give Nudds as proof that learning at too low a level certainly doesn't
*cure* logic problems, and, IMHO, can seriously weaken reasoning ability, by
hiding patterns behind a mess of details.

-s
-- 
Copyright 1997 Peter Seebach - seebs at solon.com - C/Unix Wizard
I am not actually gladys@nancynet.com but junk mail is accepted there.
The *other* C FAQ, the hacker FAQ, et al.  http://www.solon.com/~seebs
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <dewar.860207445@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon said
> 
> <<Emphasis mine.  I read "to catch overflows efficiently" as being
> interchangeable with "to avoid inefficiencies in catching overflows".
> I think Bob has already agreed with this, but that he meant to also
> say he didn't really know for sure if it worked.>>
> 
> incidentally I definitely see how you could read Bob's statement the
> way you did, rereading it. I guess the reason I did not read it that
> way was because I knew that would be a completely false implication,
> and I assumed, perhaps too charitably, that no one would make the 
> claim that it would be possible to eliminate the penalty for overflow
> checking when generating C :-)

I read it as it was written.  Period.  What is more, Bob has stated
that this was what he wrote but that he meant to indicate that he
didn't know a) if the "tricks" were really successful nor b) whether
the "tricks" involved generated C.  We all now know that it appears
that these "tricks" were not successful and in certain respects cannot
be successuful.


> You on the other hand, I guess really wanted it to be possible to 
> generate efficient C, so you were happy to read it more optimistically.

Here you are just plain wrong.  I have no desires here one way or the
other since I have no stake in the matter whatsoever.  Other than
knowing the actual facts, I don't really care about the issue at all.


> Just goes to show that it is not easy to be 100% clear in email!

This is absolutely true!

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Jon S Anthony]

In article <dewar.860206887@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon says
> 
> <<Emphasis mine.  I read "to catch overflows efficiently" as being
> interchangeable with "to avoid inefficiencies in catching overflows".
> I think Bob has already agreed with this, but that he meant to also
> say he didn't really know for sure if it worked.>>

> 
> If Bob DID mean to imply that ICC avoided all efficiency penalties
> in handling overflows in C generated code, that's just plain wrong!

No universal quantifiers are written in this nor are any presumed and
I doubt any were intended (this is absolutely true for my part).  I'm
not sure why you bring them in - they're irrelevant and confusing.


> So, let's not obscure the semantics here.

Indeed.


> The bottom line here is that there is a significant efficiency
> penalty in generating C, and it cannot be eliminated, no matter how
> clever you are!

I don't think anyone is suggesting otherwise and haven't been for some
time now...


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Ada95 to ANSI_C converter

[Arthur Schwarz]

Robert Dewar wrote:
> 
> Keith says
> 
> <<(I *like* nasty test cases)>>
> 
> The trouble with nasty test cases is that they can sometimes result in
> implementors wasting huge amounts of time getting things right that are
> of no possible concern to users. The old ACVC suite was full of such
> things, and it is still quite often the case that we make a change
> and it affects none of our user programs in our regression suite, but
> it causes an obscure bug in some ACVC test. Equally, it is often the
> case that a change blows away huge numbers of user tests, but the
> ACVC hums merrily on with no errors.
> 
> Anecdotally (we really should collect data on this, we have the raw data),
> we have the impression that the Ada 95 tests tend to track user programs
> more closely. They are certainly much less full of "nasty test cases".


(Anecdotally): One program that I wrote (Fortran IV/66) broke the
compiler.
I was told by my manager that my program 'stressed' it (the compiler).
And
at that time and since I have wondered why! If the language permits a
construct
and the compiler doesn't accept it, or what's worse, the generated code
doesn't
perform the operation correctly, then the compiler is "broke", not the
construct
and not the language. I would then say that a "nasty test case" is just
another
language construct which must be accepted by the compiler. It's only
nasty when
the compiler can not process it correctly. The same goes for 'obscure',
'seldom
used', and of course, 'of no possible use to users'. To my jaundiced eye
this all
seems to be an excuse to direct effort at 'big payoff' items, the ones
that seem
to be most likely of use. The problem is that the devil is in the
details, and it
is just those other, legal, small payoff items which cause great labor
for the 
implementor to debug; transfering the cost of the compiler from
developer to user.

Your other comment that the ACVC test does not catch all errors is valid
but I think
not very meaningful. The complexity of language and compiler and
computer and
operating system and ... conspire to make exhaustive testing too
exhaustive. If
this is accepted as an accurate statement, it would seem unlikely that
any test
suite, except for very small 'languages', could ever be exhaustive
enough to catch
all possible compiler errors.

And this is not to attempt to derate ACT or your own efforts. Only to
say that
IMO the issue is not meaningful in that failing to pass a "nasty test
case" means
that the language feature tested is not useable and the compiler
erroneous.

art

My own opinions are often my own, seldom my companies.

Re: Ada95 to ANSI_C converter

[Robert Dewar]

iArthur Schwarz says

<<And this is not to attempt to derate ACT or your own efforts. Only to
say that
IMO the issue is not meaningful in that failing to pass a "nasty test
case" means
that the language feature tested is not useable and the compiler
erroneous.>>

(by the way it would be appreicated if you keep your line length under 80!)

Yes, I know this seems reasonable to those without direct experience in
defining languages and dealing with language standards, but the fact of the
matter is that for real life languages, there are lots of murky areas which
are not so easily adjudicated, and where there is little poitn in writing
tests. The ARG found it useful to have a category "pathological", which
means, yes, the language is defined to behave in (surprising/silly/clearly-
wrong/absurd etc) manner Y, but it is not worth trying to fix it, or to
worry about it too much, since it is too marginal to be of interest (and
please, ACVC folks do NOT write stupid tests).

Note that the business in Arthur's message about "stressing a compiler" is
not relevant at all. Stressing compilers is a good thing. We are talking
about stressing the *language* here!

Re: Ada95 to ANSI_C converter

[Kaz Kylheku]

In article <5ibj89$c9j@solutions.solon.com>,
Peter Seebach <seebs@solon.com> wrote:

>I give Nudds as proof that learning at too low a level certainly doesn't
>*cure* logic problems, and, IMHO, can seriously weaken reasoning ability, by
>hiding patterns behind a mess of details.

???

Nudds has shown that he can master neither details nor the big picture.  It is
not excessive concern for detail that weakens his reasoning ability,
but, more likely, faulty brain chemistry. I wouln't offer the example of
Nudds as a proof of anything.

Re: Ada95 to ANSI_C converter

[Robert A Duff]

In article <dewar.860442122@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>tests. The ARG found it useful to have a category "pathological", which

This category was invented in 1990.  Only three Ada 83 AI's were
classified as pathological.  Many compiler writers, IMHO, are too quick
to call something pathological.  To me, pathological should mean this is
a combination of features that nobody in their right mind would use --
it has no conceivable use.  It shouldn't mean just any rare combination
of features.

One of those three AI's declared a certain feature to be erroneous,
which seems odd -- "!class pathological" on an AI means "Don't create an
ACVC test", but you can't really create an ACVC test for something
that's erroneous anyway, since any behavior whatsoever is acceptable to
pass the test.  (This was the one about tasks escaping their master,
which is prevented by accessibility checks in Ada95.)

There are no Ada 95 AI's that have been declared pathological.  There's
probably no need -- the "!class pathology" was really for protecting
compiler vendors (and hence their customers) from bizzarre tests, but
the style of the Ada 95 ACVC discourages such tests from being written.

- Bob

Re: Ada95 to ANSI_C converter

[Keith Thompson]

I've deleted comp.lang.c from the Newsgroups header.

In <dewar.860184524@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
[...]
> Anecdotally (we really should collect data on this, we have the raw data),
> we have the impression that the Ada 95 tests tend to track user programs
> more closely. They are certainly much less full of "nasty test cases".

I've always been a bit suspicious of the "user-oriented" philosophy of the
Ada 95 tests.  To over-simplify, there are only finitely many language
features, but there are potentially infinitely many user programs.
It's a lot easier to test the former than the latter.  The fact that a
compiler had to pass a bunch of somebody else's "user-oriented" tests
doesn't necessarily imply that it will work properly on *my* code.

As I said, though, this is an over-simplification.  The feature-oriented
Ada 83 ACVCs certainly didn't cover the entire language, especially when
you consider interactions between features.

Does anyone have specific examples of things that the Ada 95 ACVCs
deliberately don't test, that Ada 83-style ACVCs would have?

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
5040 Shoreham Place, San Diego, CA, USA, 92122-5989
"Humor is such a subjective thing." -- Cartagia

Re: Ada95 to ANSI_C converter

[Dan Lehman]

Re the Ada Issues / Commentaries classification "Pathological",
it bugs me each time it's mentioned, such as ...

> This category was invented in 1990.  Only three Ada 83 AI's were
> classified as pathological. ...

Indeed (which shows how important it is)!  And AI-00865 which spawned
the classification arose from a challenge to an ACVC test which most
of the expert reviewers deemed too quickly "pathological" but ultimately
one ARG reviewer made more convincing arguments that the test was plain
WRONG (as opposed to pathologically correct).  And the AI carries just
that argument, yet nevertheless waves the pathological flag.  The ACVC,
too, was summarily charged with having many "pathological" tests; but
there was never any particular citations of this affliction.

The more deserving AI to carry the classification was the old one
re accessing a task outside of its master (AI-167 (ooo, make that, now,
"AI83-00167" :-), which was classified as a Confirmation).  This was
ultimately reversed by AI83-00867, which is classified as a Pathology
--maybe the one good example of such.

> The ARG found it useful to have a category "pathological"

Well, not so terribly frequently "useful", Robert.

---Dan
------- *

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Dan said, responding to me:

<<> The ARG found it useful to have a category "pathological"

Well, not so terribly frequently "useful", Robert.>>


Well Dan, I think more useful than you think. Once the notion exists, it
acts as an important reminder that just because a torturous argument from
the RM says that a certain program should behave in a certain way, that
is not enough reason to legitimize a test for the feature.

That principle did not exist early on in the ACVC process, and damage
was done as a result -- most notably the test you cite (the "Rosen"
anomoly).

However, once the principle did exist, I think it helped change viewpoints,
and in particular was a definite factor in the development of the notion
of "usage oriented testing" which informed the development of the Ada 95
ACVC tests.

Re: Ada95 to ANSI_C converter

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.861328976@merv>...
> However, once the principle did exist, I think it helped change
viewpoints,
> and in particular was a definite factor in the development of the notion
> of "usage oriented testing" which informed the development of the Ada 95
> ACVC tests.


Yes, providing that it not seen by those outside the Ada community as a
convenient 'get out', whereby Ada compiler vendors are excused having to
conform fully to the RM. We all know that this would be completely unfair,
but outsiders might not. I agree with the "pathological" classification,
but we have to be careful that it never gets abused, bringing the Ada
language into disrepute.

Nick.

Re: Ada95 to ANSI_C converter

[Robert Dewar]

Nick says

<<Yes, providing that it not seen by those outside the Ada community as a
convenient 'get out', whereby Ada compiler vendors are excused having to
conform fully to the RM. We all know that this would be completely unfair,
but outsiders might not. I agree with the "pathological" classification,
but we have to be careful that it never gets abused, bringing the Ada
language into disrepute.>>

Sure, but as Dan points out, it has only been used in very rare
circumstances, and only a very small number of times. Note that the
test suites for COBOL and C have always been much more usage oriented
than the original ACVC suite.