Ada to C/C++ translator needed

Ada to C/C++ translator needed

[Emmanuel Champommier]

I'm looking for an Ada to C (or C++) translator.

Does anyone knows where I could find it ?

Thanks
-- 
                               E. Champommier
                           (echampommier@magic.fr)

Re: Ada to C/C++ translator needed

[David Weller]

In article <32499FA0.4B5E@magic.fr>,
Emmanuel Champommier  <echampommier@magic.fr> wrote:
>I'm looking for an Ada to C (or C++) translator.
>Does anyone knows where I could find it ?
>

Bad news:
	1) None exist
	2) None will likely ever exist (This is for various market
	reasons, as well as the fact that translating various Ada
	constructs, especially when used in combinations, would be
	literally impossible to translate (portably, or even
	semi-portably) into C _or_ C++)

Good news (kind of):
	1) A C to Ada traslator exists
	(http://www.inmet.com/~mg/c2ada/c2ada.html)
	2) A C++ to Ada translator is in early prototype stages

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Ada to C/C++ translator needed

[B|rje Norden]

David Weller wrote:
> 
> In article <32499FA0.4B5E@magic.fr>,
> Emmanuel Champommier  <echampommier@magic.fr> wrote:
> >I'm looking for an Ada to C (or C++) translator.
> >Does anyone knows where I could find it ?
> >
> 
> Bad news:
>         1) None exist
I'm not so sure about that; I seem to remember having seen an ADA
compiler that generated C code instead of object code (OK, strictly
speaking this isn't a translator,but it shows that it's not impossible
to develop code in ADA and later convert it to C/C++)

>         2) None will likely ever exist (This is for various market
>         reasons, as well as the fact that translating various Ada
>         constructs, especially when used in combinations, would be
>         literally impossible to translate (portably, or even
>         semi-portably) into C _or_ C++)
Apart from ADA's multitasking features,most of the constructs in ADA/C++
is actually quite similar (apart from syntax, that is...); I don't think
it would be too difficult to make an ADA to C++ converter if there was a
good way of handling the multitasking bits (ADA to C, on the other hand,
would be a nightmare to accomplish...;-)). And what do you mean by
various market reasons ? Please explain yourself.

> 
> Good news (kind of):
>         1) A C to Ada traslator exists
>         (http://www.inmet.com/~mg/c2ada/c2ada.html)
>         2) A C++ to Ada translator is in early prototype stages
This would be just as hard as ADA to C++...

> 
> --
>     Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
>            This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Ada to C/C++ translator needed

[David Weller]

In article <3251C855.41C6@etek.chalmers.se>,
B|rje Norden  <yes@etek.chalmers.se> wrote:
>David Weller wrote:
>> 
>> In article <32499FA0.4B5E@magic.fr>,
>> Emmanuel Champommier  <echampommier@magic.fr> wrote:
>> >I'm looking for an Ada to C (or C++) translator.
>> >Does anyone knows where I could find it ?
>
>>         2) None will likely ever exist (This is for various market
>>         reasons, as well as the fact that translating various Ada
>>         constructs, especially when used in combinations, would be
>>         literally impossible to translate (portably, or even
>>         semi-portably) into C _or_ C++)
>Apart from ADA's multitasking features,most of the constructs in ADA/C++
>is actually quite similar (apart from syntax, that is...); I don't think
>it would be too difficult to make an ADA to C++ converter if there was a
>good way of handling the multitasking bits (ADA to C, on the other hand,
>would be a nightmare to accomplish...;-)). And what do you mean by
>various market reasons ? Please explain yourself.
>

What you probably saw was the old Meridian Ada compiler for MPW on the
Mac.  My memory is just as foggy :-), but I seem to recall there were
a lot of little rules about what was, and was not, supported
syntactically.  I don't think any multitasking was supported.  Perhaps
somebody more familiar with that product could speak up.  I do recall
it had a very short life, however.

As for "market reasons", there simply isn't any benefit.  Quite
frankly, the same market reasons apply in the reverse direction.  The
truth of the entire matter is this:  Current and future languages will
be noted more by how friendly they are to "foreign languages" than by
how feature-laden they are.  As software developers, we learn, more
and more, that the world isn't monolingual when it comes to
programming languages.  I personally shift between Perl, Java, C++,
and Ada almost every day (maybe in hopes that one of these days, Ada
will recognize the $_ variable :-).  I'm writing a C++ to Ada
translator to reduce translation errors in migrating a series of
software components.  I have no hopes of selling it, but some people
may find it useful for various reasons (some may be working to a
demand to move from C++ to Ada, others may want to use it to help find
weaknesses in the C++ typing model to improve their C++ code, and,
what I REALLY hope it will be used for: people will have a
tool that will help them start to objectively compare C++ and Ada)

>> 
>> Good news (kind of):
>>         1) A C to Ada traslator exists
>>         (http://www.inmet.com/~mg/c2ada/c2ada.html)
>>         2) A C++ to Ada translator is in early prototype stages
>This would be just as hard as ADA to C++...
>

Hmm...no, I don't think so, but it would be an excellent experiment
for somebody to do (I'm keeping track of the time I apply to creating
my converter, they're welcome to use that to compare level of effort,
if nothing else).  On the simplest level, the interaction between
protected types, tasks, and controlled types in Ada would be VERY hard
to duplicate through a converter.  You'd have to have a non-trivial,
portable library to support such a thing.  I've yet to find a need to
have _any_ such library/package for the C++ to Ada translation.  

And, of course, I have no desire to waste my time with an Ada to C++
translator (but if offered the right amount of money ... :-)

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Ada to C/C++ translator needed

[Robert Dewar]

B|rje Norden said

  I'm not so sure about that; I seem to remember having seen an ADA
  compiler that generated C code instead of object code (OK, strictly
  speaking this isn't a translator,but it shows that it's not impossible
  to develop code in ADA and later convert it to C/C++)

     No, it does not show anything of the kind. The compilers that have
     generated C code have done it have generated extremely low level
     C that you would not think of having a human read.

     Obviously it is possible in a limited sense to generate output in
     C syntax that maps the original Ada semantics to C syntax. For instance,
     you could make a gcc backend, which generated assembler level C:

         r1 = r2 + r3;
         if (r1 > 0) goto l345;
         r4 = mem[sp];
         ...

     etc, but such a "C" program is no more interesting from a maintainability
     point of view than intermediate assembly language. It is a possible path
     to an interesting level of portability for the Ada compiler, which is why
     it has been used for at least one Ada compiler in the past.

Apart from ADA's multitasking features,most of the constructs in ADA/C++
is actually quite similar (apart from syntax, that is...); I don't think
it would be too difficult to make an ADA to C++ converter if there was a
good way of handling the multitasking bits (ADA to C, on the other hand,
would be a nightmare to accomplish...;-)). And what do you mean by
various market reasons ? Please explain yourself.

  Actually the multi-tasking parts are the easiest, since they are just
  library routines that have to be written and then called in the right
  places.

  The real difficulty, you actually state: **quite** similar. That **quite**
  is deadly. It means that the semantics do not correspond exactly, and you
  will find in practice that once you delve into the details, that this is
  one of those cases that has given rise to the phrase "the devil is in the
  details". Writing a complete translator from C++ to Ada 95 (or vice versa)
  would be very much harder than writing two compilers for each language
  separately. You would have to understand 100% of the semantics of both
  languages, and constantly be intermediating fights between them.

Re: Ada to C/C++ translator needed

[Frank Manning]

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

    <discussion of Ada-to-C translator>

>       ...such a "C" program is no more interesting from a maintainability
> point of view than intermediate assembly language. It is a possible path
> to an interesting level of portability for the Ada compiler, which is why
> it has been used for at least one Ada compiler in the past.

Eh? Where can I get one of these compilers?

Awhile back there was a big discussion about the merits of writing an
8051 Ada compiler. I'm a bit surprised nobody mentioned this
possibility, since 8051 C compilers already exist.

-- Frank Manning
-- Chair, AIAA-Tucson Section

Re: Ada to C/C++ translator needed

[Samuel Tardieu]

>>>>> "Frank" == Frank Manning <frank@bigdog.engr.arizona.edu> writes:

Frank> Awhile back there was a big discussion about the merits of
Frank> writing an 8051 Ada compiler. I'm a bit surprised nobody
Frank> mentioned this possibility, since 8051 C compilers already
Frank> exist.

You've hit another interesting point: is there a study on how hard
(man*year) it is to write machine-specifics files for GCC ? I've never
had to write some since all the targets I use are supported already,
but it doesn't seem to be an unreasonable task at all. Once these
files are written, you get a cross-compiler for C, C++, Obj-C,
Fortran, Modula and Ada (not including the runtimes which are highly
machine dependents, but if you use an Ada to C translator, you will
have to write the tasking library to be called from C anyway, so it
shouldn't be a more complicated job to port the Ada runtime itself).

  Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org

Re: Ada to C/C++ translator needed

[Richard Kenner]

In article <qw6iv8o9yig.fsf@gargantua.enst.fr> Samuel Tardieu <sam@ada.eu.org> writes:
>You've hit another interesting point: is there a study on how hard
>(man*year) it is to write machine-specifics files for GCC ?

There's certainly been no "study", but there is anecdotal evidence.

Unfortunately, it isn't too useful because the answer is a strong
function of who's doing it and how "peculiar" the machine in question is.

For example, I did the GCC config files for the RS/6000 in about a
month of elapsed time, working about 50% of my time on that.  Much of
that time was spent fighting IBM's assembler.

The Alpha was faster since the assembler problems didn't exist.

If you're very familiar with GCC, you can make a first cut at the
config files in a few days, at which point you can start generating
code and testing by bootstrapping it.  If the machine is relatively
conventional, there are no problem with vendor tools such as the
assembler, sufficient documentation is available, and the machine is
fast enough so compile times are not an issue, it's reasonable to
think of being able to get the compiler to bootstap in about 2-3
man-weeks of work.

But if any of the above aren't true, it can be considerably longer.
For machines that can't host GCC, you also have a harder problem in
testing it since you can just do a bootstrap.  Also, at times you have
to add facilities to GCC to support a new machine, though the last few
that have been added didn't need any such.

If you don't know GCC, the time to learn it needs to be added to this.
That can be as much as 1-3 months, depending on the person.

Re: Ada to C/C++ translator needed

[Robert Dewar]

Richard said


"Unfortunately, it isn't too useful because the answer is a strong
function of who's doing it and how "peculiar" the machine in question is.

For example, I did the GCC config files for the RS/6000 in about a
month of elapsed time, working about 50% of my time on that.  Much of
that time was spent fighting IBM's assembler.

The Alpha was faster since the assembler problems didn't exist."

Of course, getting to the first version of the GCC config files is only
part of producting a complete port in a productized form, but still we
are typically talking of perhaps a person year in all, so not a big effort.
Certainly it is probably just as easy to create a new MD fie for GCC as
it would be to get a compiler working via a C translation, and you get
much better results from the former approach.

Re: Ada to C/C++ translator needed

[Stephen Leake]

Having just helped write the MD files for a VERY simple chip (the
UT69R000), I can provide another anecdote.

I started with NO knowledge of gcc, an MD files that were copied from
some other chip and edited. It was fairly easy to get simple C code to
work (on the level of A = B + 1). But when I got to functions with many
statements, and the register allocation kicked in, things got
complicated very quickly. I had to learn how gcc allocated registers,
and how to make the MD files work with that process. Reading other MD
files helped a lot, and the gcc code is pretty well commented, but it
wasn't easy.

All told, it was six months before I got the C compiler to pass most of
an ANSI validation suite. I haven't gotten to testing the Ada compiler
yet (I'm working on other stuff); nested procedures and exception
handling may uncover another level of bugs. If the chip you are porting
to is at all complex, incorporating that complexity will take more time,
too.

On the whole, it was a rewarding experience; if you like complex
puzzles, go for it!
-- 
- Stephe

Re: Ada to C/C++ translator needed

[Robert Dewar]

Frank said

"Awhile back there was a big discussion about the merits of writing an
8051 Ada compiler. I'm a bit surprised nobody mentioned this
possibility, since 8051 C compilers already exist."

If you think that the existence of an Ada 83 compiler that generates C 
means that there is an easy path to an acceptably efficient Ada compiler
on any machine with a C compiler, you are seriously fooling yourself for
all sorts of reasons. Nothing is as straightforward as one might hope!

Re: Ada to C/C++ translator needed

[Frank Manning]

Robert said

> If you think that the existence of an Ada 83 compiler that generates C 
> means that there is an easy path to an acceptably efficient Ada compiler
> on any machine with a C compiler, you are seriously fooling yourself for
> all sorts of reasons.  [...] 

I seriously fool myself all the time. Nothing new about that :-)

Re: Ada to C/C++ translator needed

[Erik Magnuson]

dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:

> 
> Frank said
> 
> "Awhile back there was a big discussion about the merits of writing an
> 8051 Ada compiler. I'm a bit surprised nobody mentioned this
> possibility, since 8051 C compilers already exist."
> 
> If you think that the existence of an Ada 83 compiler that generates C 
> means that there is an easy path to an acceptably efficient Ada compiler
> on any machine with a C compiler, you are seriously fooling yourself for
> all sorts of reasons. Nothing is as straightforward as one might hope!
> 

In a former life, I used to use such a beast daily and quickly came to
realize just why this is not a favored path to what we would call a
"production quality compiler". (No offense to the vendor intended, it was
impressive that it worked as well as it did.)

Realize that if you want to get decent performance even writing low-level C
these days you have to enable the C compiler's optimizer. You can imagine
what contortions the code generator has to go through to make sure the C
optimizer does not hose the Ada semantics.  Not to mention to workaround the
bugs in said optimizer (which change in every release.)  Especially since
the C compiler vendor's test suite is very unlikely to contain such odd
code. (Imagine reporting such bugs to the C vendor: "You're doing what?!").

And think about how much fun debugging becomes. For if you have no Ada code
generator, you're not likely to have an Ada debugger!  Oh, the joy of trying
to make sense of 3 listings (the Ada source, the generated C and the
generated assembler.)  It was not pretty. Supporting nested
procedures was a particular joy to behold.  

In addition, I believe that 8051 C compilers tend to have extensions to
exploit the features of the chip. You'll want these of course. You'll have
lots of fun trying to decide how to map onto these. 

And the compilation speed will be at least twice as bad as the C
compiler. Think about it: you have at least the entire C compiler overhead
as well as your Ada compiler source -> code gen (including the Ada
compiler's highlevel optimizer.)  (For this example, imagine the C compiler
is a hasty port of a Unix compiler to VMS that does lot's unixy things that
VMS just hates, like spawning many processes that communicate via temp files
that are byte streams, etc.) 

-- 
Erik Magnuson, ENSCO	erik@fl.ensco.com
MARSS-REPL  		(407) 783-7114

Re: Ada to C/C++ translator needed

[Ian Ward]

In article 4B5E@magic.fr, Emmanuel Champommier <echampommier@magic.fr> () writes:
>I'm looking for an Ada to C (or C++) translator.
>
>Does anyone knows where I could find it ?
>
>Thanks
>-- 
>                               E. Champommier
>                           (echampommier@magic.fr)
>

I have seen this request several times, and it seems to me
to be not an easy thing to write. Converting 'C' to Ada, I 
guess involves a lot less donkey work than the other way 
around.

This is because for almost each construct in 'C' and 'C++'
(that I can think of,) there is an almost identical
construct in Ada, though perhaps with a different
syntactical layout. Thus, converting from 'C'/C++ to Ada
involves merely rewording the text. (In fact, I have 
heard that Java is even more similar to Ada, than either
'C' or C++, so presumably this goes for Java as well)

Conversely, Ada has features, such as exception handling,
range checking, and typing, (not to mention multithreaded
tasking, protected and private types, and generics,) that
do not simply involve a straight rewording of the code. 

My guess that writing an Ada to 'C'/C++ to convertor would be
almost as difficult as writing a compiler, which is why I
have not heard of one. Not only that, but the people who
have been writing Ada compilers, while having had a shaky
start, (very shaky in the 80's) have basically cracked all
the difficult bits of the language (for Ada83 at least) which
is why Ada compilers are now more or less on par with 'C'
compilers. Starting from scratch into 'C' would take quite
some time to approach, I think, the levels of optimisation
that a straight compile of the Ada to an object file would
take. It would make sense I think, just to link in the 
object files, assuming you can, to your 'C'. (I say this
because I know it is possible with GNAT, but I am not so
sure with other compilers. Though I have not come across
an Ada compiler yet that could not link the other way.)

I think a convertor like this would provide a great many
people, a lot of fun to work on. However, it does seem
just a bit pointless. As time goes on, it shall become a 
greater and greater requirement for a language to interface
with others, bearing in mind the huge quantities of legacy 
code, (growing in size every day.)

---
Ian Ward's opinions only : wardi@rsd.bel.alcatel.be

Re: Ada to C/C++ translator needed

[Jon S Anthony]

In article <52o1ve$gra@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >I hope you're not suggesting that comparing compilers on one
> >system with one program tells you *anything* about the relative
> >merits of languages ...
> 
> Of course I am.  Have you no logic in you at all, man?

Of course he doesn't.  Tim has shown himself to have only the feeblest
grasp of logic in several recent threads.

> Here's what it tells me:
> 
> 	not (forall X: Problem
> 	     forall S: System
> 	     forall A: Ada_Compiler
> 	     forall C: C_Compiler
> 	     runs_on(A, S) & runs_on(C, S) =>
> 	     slower(code(X, A), code(X, C))
> 	    )

You don't actually expect this guy to understand this, do you?!?!??

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Ada to C/C++ translator needed

[Jon S Anthony]

In article <01bbaef3$73605680$87ee6fce@timpent.a-sis.com> "Tim Behrendsen" <tim@a-sis.com> writes:

> All that having been said, I wonder how much bounds checking
> is actually kept in a real good-sized project where you are
> passing general values into subroutines that get used as
> array indexes (where the compiler couldn't necessarily validate
> at compile time)?

Perhaps you have not seen the other posts.  If you are so inclined you
can field the software with "all" checks removed.  Sure, in most
circumstances this makes little to no sense, but if that is what you
want just do it.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<52feul$os2@goanna.cs.rmit.edu.au>...
> In article 4B5E@magic.fr, Emmanuel Champommier <echampommier@magic.fr> ()
writes:
> >I'm looking for an Ada to C (or C++) translator.
> 
> wardi@rsd.bel.alcatel.be (Ian Ward) writes:
> >[He thinks it would be hard and points out that Ada compilers
> > are now very good.]
> 
> Just for the record, here's the result of a speed test between C, Ada,
> Scheme, and Fortran versions of the same numerical program, on an
UltraSPARC.
> cc and f77 are SPARCompiler C and Fortran version 4.0.
> gnat is 3.04 with gcc back end 2.7.2.  stalin was version 0.6.
> 
>    cc           30 seconds
>    gnat         27 seconds
>    stalin	26 seconds (Siskind's Scheme->C then gcc 2.7.2)
>    f77          25 seconds
> 
> The f77 code came from a book.  I wrote the C, Ada, and Scheme versions.
> I am fluent in C and Scheme, striving to become so in Ada.
> 
> I can't think of any reason to convert the Ada code to C,
> especially as the Ada compiler that got this result is free
> and supports the Ada 95 *standard* interface with C, so that calling
> existing C code from Ada is a breeze.

I hope you're not suggesting that comparing compilers on one
system with one program tells you *anything* about the relative
merits of languages ...

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Ken Pizzini]

In article <01bbad6e$67743f20$32ee6fcf@timhome2>,
Tim Behrendsen <tim@airshields.com> wrote:
>Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
><52feul$os2@goanna.cs.rmit.edu.au>...
>> Just for the record, here's the result of a speed test between C, Ada,
>> Scheme, and Fortran versions of the same numerical program, on an
>> UltraSPARC.
>> cc and f77 are SPARCompiler C and Fortran version 4.0.
>> gnat is 3.04 with gcc back end 2.7.2.  stalin was version 0.6.
>> 
>>    cc           30 seconds
>>    gnat         27 seconds
>>    stalin	26 seconds (Siskind's Scheme->C then gcc 2.7.2)
>>    f77          25 seconds
>> 
>> The f77 code came from a book.  I wrote the C, Ada, and Scheme versions.
>> I am fluent in C and Scheme, striving to become so in Ada.
>> 
>> I can't think of any reason to convert the Ada code to C,
>> especially as the Ada compiler that got this result is free
>> and supports the Ada 95 *standard* interface with C, so that calling
>> existing C code from Ada is a breeze.
>
>I hope you're not suggesting that comparing compilers on one
>system with one program tells you *anything* about the relative
>merits of languages ...

What I read in his results is that the quality of a compiler is
more important to performance than the language.  Ignoring
the cc result the value "26 +/- 1 seconds" sounds pretty even.
It would be interesting (to me, not this group) to know how
gcc 2.7.2 would do on the C version of the program, since it
shares the same back-end as gnat, and is the C compiler used
by the stalin test.

		--Ken Pizzini

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Ken Pizzini <ken@coho.halcyon.com> wrote in article
<52ltk5$qlf@news1.halcyon.com>...
> In article <01bbad6e$67743f20$32ee6fcf@timhome2>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
> >>[snip numerical program test UltraSparc; cc: 30s, gnat: 27s,]
> >>[stalin 26s (Scheme), f77: 25s]
> >> 
> >> I can't think of any reason to convert the Ada code to C,
> >> especially as the Ada compiler that got this result is free
> >> and supports the Ada 95 *standard* interface with C, so that calling
> >> existing C code from Ada is a breeze.
> >
> >I hope you're not suggesting that comparing compilers on one
> >system with one program tells you *anything* about the relative
> >merits of languages ...
> 
> What I read in his results is that the quality of a compiler is
> more important to performance than the language.  Ignoring
> the cc result the value "26 +/- 1 seconds" sounds pretty even.
> It would be interesting (to me, not this group) to know how
> gcc 2.7.2 would do on the C version of the program, since it
> shares the same back-end as gnat, and is the C compiler used
> by the stalin test.

Oh, most definitely the quality of the compiler is everything (how
could it not be?).  The context of the thread is conversion of an
Ada program to a C program, and it seems as if these numbers
were meant to "prove" that Ada can be just as efficient as C,
which is apparently true for this one program on this one platform.

However, to generalize on that basis that Ada is *always* as
efficient as C is dangerous thinking, particularly for the original
poster's "real" application software that he wants to convert to C.

In fact, I can show you APL lines of code that could potentially
beat an equivalent C program (because there are so many fundamental
primitives are are natively implemented), but that doesn't mean
I want to write MS/Word using APL.

And BTW, it may well be *true* that Ada can be as efficient
as C.  You simply can't prove it in this manner.  Show me a CAD
system, RDBMS, heck, id Software's Quake! written in both C and
Ada (or Scheme) using the same algorithms, and *then* tell me the
results.

Actually, id *does* release the C source code of Wolfenstein 3D,
the first real first-person texture-mapped game.  It would be an
amusing project to convert it to various languages and see what
happens, e.g., how much time to compute a frame.

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Robert Dewar]

Tim said

"Actually, id *does* release the C source code of Wolfenstein 3D,
the first real first-person texture-mapped game.  It would be an
amusing project to convert it to various languages and see what
happens, e.g., how much time to compute a frame."

Even such an experiment would not say much. It is certainly possible,
given any C program, to write an Ada program that generates identical
code in a GCC environment (GNU C and GNAT share the same backend of 
course), but that does not prove much. In practice, one would want to
take advantage of the high level features of Ada not present in C,
and you could get results varying all over the map depending on how
you chose to program it.

What is certainly true is that you are no worse off in Ada than in C. At
worst, you can program at a low level approximating C semantic level,
and you will get code of identical efficiency to C, so moving to C for
the sake of efficienfy alone makes no sense at all.

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Robert Dewar <dewar@schonberg.cs.nyu.edu> wrote in article
<dewar.844055713@schonberg>...
> Tim said
> 
> "Actually, id *does* release the C source code of Wolfenstein 3D,
> the first real first-person texture-mapped game.  It would be an
> amusing project to convert it to various languages and see what
> happens, e.g., how much time to compute a frame."
> 
> Even such an experiment would not say much. It is certainly possible,
> given any C program, to write an Ada program that generates identical
> code in a GCC environment (GNU C and GNAT share the same backend of 
> course), but that does not prove much. In practice, one would want to
> take advantage of the high level features of Ada not present in C,
> and you could get results varying all over the map depending on how
> you chose to program it.
> 
> What is certainly true is that you are no worse off in Ada than in C. At
> worst, you can program at a low level approximating C semantic level,
> and you will get code of identical efficiency to C, so moving to C for
> the sake of efficienfy alone makes no sense at all.

I know that Ada does run-time checks of array bounds that C
doesn't do; that could be one source of loss of performance.
Does Ada do any other run-time checks that C doesn't do?

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Matthew Heaney]

In article <01bbae8f$dffbd440$32ee6fcf@timhome2>, "Tim Behrendsen"
<tim@airshields.com> wrote:

>I know that Ada does run-time checks of array bounds that C
>doesn't do; that could be one source of loss of performance.
>Does Ada do any other run-time checks that C doesn't do?

Not necessarily.  Using a subtype actually *turns off* type checking during
iteration through an array.  

If I did this

   type AT is array (Positive range <>) of T;

   O : AT (1 .. 10);
begin
   for I in 1 .. 10 loop
      O (I) :- ...

Then I might very well incur a check.  But by asserting a more specific
type for the loop index, no checks will be made inside the loop:

   for I in O'Range loop
      O (I)   -- no check, since I is guaranteed to to be in the range of O

Or

   subtype Index is Positive range 1 .. 10;

   O : AT (Index);
begin
   for I in Index loop
      O (I)  -- no check required inside the loop

If I didn't want to iterate through all the items in O, then I (the human)
would still include a subtype for I (the index):

   O : AT (Index);
begin
   for I in Index range 2 .. 8 loop
      O (I)...

Here you are asserting that I lies in the index subtype of O.  The checking
of that assertion need only take place once, on entry to the loop.

It's a common misunderstanding that a subtype puts checks in, but very
often just the opposite is true.  The idea is the give the compiler as much
information as you can when declaring the index that dereferences an array
object.  For example:

   O : AT (1 .. 10);
   I : Positive range O'Range; 
begin
   ...
   O (I) ...   -- no check required

or

   subtype Index is Positive range 1 .. 10;
   O : AT (Index);
   I : Index;
begin
   ...
   O (I) ...

>-- Tim Behrendsen (tim@a-sis.com)

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Matthew Heaney <mheaney@ni.net> wrote in article
<mheaney-ya023180003009960805430001@news.ni.net>...
> In article <01bbae8f$dffbd440$32ee6fcf@timhome2>, "Tim Behrendsen"
> <tim@airshields.com> wrote:
> 
> >I know that Ada does run-time checks of array bounds that C
> >doesn't do; that could be one source of loss of performance.
> >Does Ada do any other run-time checks that C doesn't do?
> 
> Not necessarily.  Using a subtype actually *turns off* type checking during
> iteration through an array.  
> [snip example]

> Here you are asserting that I lies in the index subtype of O.  The checking
> of that assertion need only take place once, on entry to the loop.
> 
> It's a common misunderstanding that a subtype puts checks in, but very
> often just the opposite is true.  The idea is the give the compiler as much
> information as you can when declaring the index that dereferences an array
> object.  For example:
>[snip example]

So it is possible to give the compiler enough hints to eliminate
the check in looping cases.  In fact, I would expect the compiler
could be smart enough to detect (excuse C syntax)

for (i = 0; i < n; ++i) {
    if (A[i] > j)
        ...
}

It knows the working range of i is 0..n, so it could do the
bounds check once (A[n]) at the beginning of the loop.

All that having been said, I wonder how much bounds checking
is actually kept in a real good-sized project where you are
passing general values into subroutines that get used as
array indexes (where the compiler couldn't necessarily validate
at compile time)?

To tell you the truth, I doubt it's a big deal, unless the
latter subroutine call is being used in a hard loop, and you're
doing character-by-character processing or something. Then the
bounding checks could start adding up.

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[William Clodius]

Tim Behrendsen wrote:
> 
> <snip>
> 
> I know that Ada does run-time checks of array bounds that C
> doesn't do; that could be one source of loss of performance.
> Does Ada do any other run-time checks that C doesn't do?
> 
> -- Tim Behrendsen (tim@a-sis.com)

I believe that the Ada standard requires that all compilers be able to
perform the equivalent of the runtime checks, but allows the compilers
to have a switch to turn off these checks. Most (all?) compilers contain
such a switch, and most (all?) compilers do sufficient static analysis
to usually eliminate the vast majority of checks even without the
switch.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: Ada to C/C++ translator needed

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>I know that Ada does run-time checks of array bounds that C
>doesn't do; that could be one source of loss of performance.
>Does Ada do any other run-time checks that C doesn't do?

It is seriously misleading to say that Ada "does" run-time checks
that C doesn't.  To start with, there are (very useful) C implementations
that do bounds checks at run time, and the C standard was carefully
crafted to allow this (one possible area of conflict was the struct hack,
but it has been rules that the struct hack is not legal C any more).
The second point is that bounds checks can very often be eliminated
by the optimiser.  This is an *old* result (the first mention I saw of
it was in one of the SETL papers back in the early 70s).  It should be
obvious that 
	for I in A'Range loop ... use A(I) ... end loop;
isn't going to need any range checks, even when the bounds of A are
dynamic.  A lot of Ada array references are of this form.  A recent
paper which I think was talking about Fortran (the relevant proceedings
are not in this office right now) claimed 95% elimination.  And to finish,
pragma Suppress can be used to request supression of many checks,
including bounds checks.  It's win-win: you get the *choice*.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada to C/C++ translator needed

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>However, to generalize on that basis that Ada is *always* as
>efficient as C is dangerous thinking, particularly for the original
>poster's "real" application software that he wants to convert to C.

No such generalisation has been made by anyone, except by you as
a straw man.  All that has been offered is a disproof of the
*opposite* generalisation (that C is always more efficient than Ada).

>In fact, I can show you APL lines of code that could potentially
>beat an equivalent C program (because there are so many fundamental
>primitives are are natively implemented), but that doesn't mean
>I want to write MS/Word using APL.

I didn't talk about something _potentially_ more efficient,
I talked about something that is *actually* more efficient.

Why doesn't Behrendsen understand the *really* important point
about my posting?  Surely it was obvious that
 - obtaining, installing, and using a FREE Ada compiler that can
   generate very good code on a wide range of platforms, and
   NOT converting the code, but continuing to maintain it in Ada
stands an excellent chance of being *CHEAPER* than
 - converting Ada to C, partly by tool, partly by hand, and
   then trying to maintain the result in C.


>And BTW, it may well be *true* that Ada can be as efficient
>as C.  You simply can't prove it in this manner.

I am *sick* of Behrenden's debating tricks.
NOONE WAS *TRYING* to prove that Ada is always as efficient as C.\
All I trying to do, and what I *succeeded* in doing, was
*DIS*proving the popular contrary belief.

>Show me a CAD
>system, RDBMS, heck, id Software's Quake! written in both C and
>Ada (or Scheme) using the same algorithms, and *then* tell me the
>results.

Pay for my time, and I'll do it.  My time costs A$140/hour.
Put up or shut up.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<52o2eg$hfl@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >However, to generalize on that basis that Ada is *always* as
> >efficient as C is dangerous thinking, particularly for the original
> >poster's "real" application software that he wants to convert to C.
> 
> No such generalisation has been made by anyone, except by you as
> a straw man.  All that has been offered is a disproof of the
> *opposite* generalisation (that C is always more efficient than Ada).

From your other post:

  "If an expensive optimising C compiler (developed for a specific machine,
  with *intimate* knowledge of that machine) can't beat a free Ada compiler
  which runs on a wide range of machines, when given idiomatic code for a
  fairly straightfoward program, what would _you_ conclude?"

Sounds like a generalisation to me.

Considering that your performance comparisons in your original post
was based on a "numerical program", this tells you *nothing* about
other classes of problems.  To quote you, "Have you no logic, man?"  

> >In fact, I can show you APL lines of code that could potentially
> >beat an equivalent C program (because there are so many fundamental
> >primitives are are natively implemented), but that doesn't mean
> >I want to write MS/Word using APL.
> 
> I didn't talk about something _potentially_ more efficient,
> I talked about something that is *actually* more efficient.

You talked about one type of problem on one machine.  You obviously
have never tried to create benchmark program.  Performance can vary
*dramatically* between different compilers with the *same* language,
much less different languages!

> Why doesn't Behrendsen understand the *really* important point
> about my posting?  Surely it was obvious that
>  - obtaining, installing, and using a FREE Ada compiler that can
>    generate very good code on a wide range of platforms, and
>    NOT converting the code, but continuing to maintain it in Ada
> stands an excellent chance of being *CHEAPER* than
>  - converting Ada to C, partly by tool, partly by hand, and
>    then trying to maintain the result in C.

Why doesn't O'Keefe understand that that the latter point would
be a good point had he made it, and not posted statistically
insignificant garbage to try and justify some dubious conclusion?

I agree that conversion of the fellow's Ada program is probably
a bad idea, but that wasn't the point.  The point is that the
justification you gave was worthless, and I hope any students
out there don't learn that you can make any general conclusion
from little trivial programs run on one particular environment.

> >And BTW, it may well be *true* that Ada can be as efficient
> >as C.  You simply can't prove it in this manner.
> 
> I am *sick* of Behrenden's debating tricks.
> NOONE WAS *TRYING* to prove that Ada is always as efficient as C.\
> All I trying to do, and what I *succeeded* in doing, was
> *DIS*proving the popular contrary belief.

And I'm sick of your ranting when you're caught posting something
that makes no sense.  You have disproved *nothing*!  All you have
disproven is, for the set of all programs, there exists no program
on any platform using any compiler that is faster in Ada than C.
And no one that I know of has ever made that assertion.  Talk about
knocking down straw men!

> >Show me a CAD
> >system, RDBMS, heck, id Software's Quake! written in both C and
> >Ada (or Scheme) using the same algorithms, and *then* tell me the
> >results.
> 
> Pay for my time, and I'll do it.  My time costs A$140/hour.
> Put up or shut up.

It's not my assertion to prove.  If you want to show that Ada
can be just as efficient as C, then prove it in a non-trivial
program using a mix of algorithm theory.

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>I hope you're not suggesting that comparing compilers on one
>system with one program tells you *anything* about the relative
>merits of languages ...

Of course I am.  Have you no logic in you at all, man?
Here's what it tells me:

	not (forall X: Problem
	     forall S: System
	     forall A: Ada_Compiler
	     forall C: C_Compiler
	     runs_on(A, S) & runs_on(C, S) =>
	     slower(code(X, A), code(X, C))
	    )

If an expensive optimising C compiler (developed for a specific machine,
with *intimate* knowledge of that machine) can't beat a free Ada compiler
which runs on a wide range of machines, when given idiomatic code for a
fairly straightfoward program, what would _you_ conclude?

*Every* time I have bothered to write the same thing in Ada and C, I have
obtained the same results on this machine.  There isn't anything about the
SPARC that should tip the balance in favour of Ada.  Quite the reverse, in
fact.


-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada to C/C++ translator needed

[Peter Seebach]

In article <52o1ve$gra@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>If an expensive optimising C compiler (developed for a specific machine,
>with *intimate* knowledge of that machine) can't beat a free Ada compiler
>which runs on a wide range of machines, when given idiomatic code for a
>fairly straightfoward program, what would _you_ conclude?

That the expensive optimising C compiler was a ripoff.  :)

(However, if you're discussing SparcWorks C, you've failed to establish
that it's a C compiler.  A C compiler *MUST* diagnose the line
	static int i = 1 ? 1 : (++j);
as a constraint violation, but at least the version we have doesn't, even
in "maximally conforming ANSI mode".  Clearly, it is not a C compiler.)

>*Every* time I have bothered to write the same thing in Ada and C, I have
>obtained the same results on this machine.  There isn't anything about the
>SPARC that should tip the balance in favour of Ada.  Quite the reverse, in
>fact.

Didn't you know?  It's an acronym for "Sun's Project Ada Revenge Chip", and
was designed to make things run 10 times faster in Ada than they would have
otherwise.  :)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

Re: Ada to C/C++ translator needed

[Richard A. O'Keefe]

seebs@solutions.solon.com (Peter Seebach) writes:

>(However, if you're discussing SparcWorks C, you've failed to establish
>that it's a C compiler.  A C compiler *MUST* diagnose the line
>	static int i = 1 ? 1 : (++j);
>as a constraint violation, but at least the version we have doesn't, even
>in "maximally conforming ANSI mode".  Clearly, it is not a C compiler.)

"gub.c", line 1: undefined symbol: j

Looks like an error message to me.
Oh, you wanted something _else_ in the program?

Fair enough, given an appropriate declaration for j,
this line gets through

	SPARCompiler C, even with "-erroff=%none"
	SPARCompiler Lint
	LCLint		(shock horror; I have reported this as a bug)
	lcc		(*published* as a C compiler!)
			(I have reported this as a bug too)
	gcc -ansi -pedantic	(I'll let you report this one, seebs)

Evidently, by your argument, I haven't _got_ any C compilers to test!

>Didn't you know?  It's an acronym for "Sun's Project Ada Revenge Chip", and
>was designed to make things run 10 times faster in Ada than they would have
>otherwise.  :)

Literal-minded readers: note the smiley.
-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada to C/C++ translator needed

[Lawrence Kirby]

In article <52t8da$2ej@goanna.cs.rmit.edu.au>
           ok@goanna.cs.rmit.edu.au "Richard A. O'Keefe" writes:

>seebs@solutions.solon.com (Peter Seebach) writes:
>
>>(However, if you're discussing SparcWorks C, you've failed to establish
>>that it's a C compiler.  A C compiler *MUST* diagnose the line
>>       static int i = 1 ? 1 : (++j);
>>as a constraint violation, but at least the version we have doesn't, even
>>in "maximally conforming ANSI mode".  Clearly, it is not a C compiler.)
>
>"gub.c", line 1: undefined symbol: j
>
>Looks like an error message to me.
>Oh, you wanted something _else_ in the program?
>
>Fair enough, given an appropriate declaration for j,
>this line gets through
>
>        SPARCompiler C, even with "-erroff=%none"
>        SPARCompiler Lint
>        LCLint          (shock horror; I have reported this as a bug)
>        lcc             (*published* as a C compiler!)
>                        (I have reported this as a bug too)
>        gcc -ansi -pedantic     (I'll let you report this one, seebs)
>
>Evidently, by your argument, I haven't _got_ any C compilers to test!

Possibly, but you haven't proved it. You have to consider 6.4:

"An implementation may accept other forms of constant expression"

However I would certainly expect a lint to flag it as non-portable.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<52o1ve$gra@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >I hope you're not suggesting that comparing compilers on one
> >system with one program tells you *anything* about the relative
> >merits of languages ...
> 
> Of course I am.  Have you no logic in you at all, man?
> Here's what it tells me:
> 
> 	not (forall X: Problem
> 	     forall S: System
> 	     forall A: Ada_Compiler
> 	     forall C: C_Compiler
> 	     runs_on(A, S) & runs_on(C, S) =>
> 	     slower(code(X, A), code(X, C))
> 	    )
> 
> If an expensive optimising C compiler (developed for a specific machine,
> with *intimate* knowledge of that machine) can't beat a free Ada compiler
> which runs on a wide range of machines, when given idiomatic code for a
> fairly straightfoward program, what would _you_ conclude?

I would conclude that for that *specific* problem, the C compiler
did a bad job of optimization.  As I frequently point out (and
I frequently get abuse for it), optimizers are very imperfect
beasts at best.

Do you doubt that if we brought the writers of the Sun compiler
and had them fix their optimizer, they couldn't make it produce
*exactly* the same code as the Ada compiler (or Fortran compiler,
for that matter)?  Of course they could.

The real question that you refuse to come to terms with is, what
is the average case over a large set of compilers over a large set
of non-trivial programs over a large set of problem types?  And
this is a very difficult question to answer.

Your suggestion that comparing compilers on one platform for
one program tells you something significant is laughable at
best.

> *Every* time I have bothered to write the same thing in Ada and C, I have
> obtained the same results on this machine.  There isn't anything about the
> SPARC that should tip the balance in favour of Ada.  Quite the reverse, in
> fact.

Sounds like it's a crappy C optimizer to me, especially considering
the wide disparity between the C results and the other languages.
*This* is a reasonable conclusion.  If you have bothered to write
other programs in C and Ada, that would indicate to me that they
were trivial algorithms, and therefore your conclusions invalid.

Look at it this way; if I implement an algorithm in two languages,
C and C++, and compare the results, they will probably be very
similiar (if not identical).  However, let's take a very large
project with two teams of people, and have 1 implement the project
using C, and one implement it using C++.

I have no formal study for this, but speaking to many people who
have gone through the process, and reading a lot about many
manager's experiences, I have heard a common theme: Projects
implemented using OOP within the C++ language have experienced
significant performance problems because of the overhead of class
structures, heavy dependance on dynamic memory allocation, and the
difficulty in designing good object classes.

This is not because of optimization; this is because of the
language and style in which projects are implemented.  Now,
this is a significant debatable question.  Comparing the output
of optimizers is completely worthless to the central question
of whether REAL WORLD projects can be implement efficiently in
a particular language or not.

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Peter Seebach]

In article <01bbaee1$00ee1c20$87ee6fce@timpent.a-sis.com>,
Tim Behrendsen <tim@a-sis.com> wrote:
>I would conclude that for that *specific* problem, the C compiler
>did a bad job of optimization.  As I frequently point out (and
>I frequently get abuse for it), optimizers are very imperfect
>beasts at best.

... Right, so we *know* for sure that there exists at least one case in which
C may be less efficient than Ada.

This proves, absolutely, that the general statement "C is more efficient than
Ada" is not true.

>Do you doubt that if we brought the writers of the Sun compiler
>and had them fix their optimizer, they couldn't make it produce
>*exactly* the same code as the Ada compiler (or Fortran compiler,
>for that matter)?  Of course they could.

True.  Could they beat the Ada or Fortran compiler?  Not as likely.
Could they guarantee that, in the end, they would be able to produce better
code than the Ada compiler team?  No.

>The real question that you refuse to come to terms with is, what
>is the average case over a large set of compilers over a large set
>of non-trivial programs over a large set of problem types?  And
>this is a very difficult question to answer.

Yes.  So difficult that it's essentially irrelevant.  For that matter, a large
set of compilers has little relevance; all I care about is the best available
compilers.

>Your suggestion that comparing compilers on one platform for
>one program tells you something significant is laughable at
>best.

It does, though.  It gives you a boundary.

>This is not because of optimization; this is because of the
>language and style in which projects are implemented.  Now,
>this is a significant debatable question.  Comparing the output
>of optimizers is completely worthless to the central question
>of whether REAL WORLD projects can be implement efficiently in
>a particular language or not.

"can be" and "will be" are completely different questions.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<52p7hl$kq4@solutions.solon.com>...
> In article <01bbaee1$00ee1c20$87ee6fce@timpent.a-sis.com>,
> Tim Behrendsen <tim@a-sis.com> wrote:

> >Your suggestion that comparing compilers on one platform for
> >one program tells you something significant is laughable at
> >best.
> 
> It does, though.  It gives you a boundary.

You mean a boundary in the sense that you have a baseline by
which to compare a compiler in order to determine if it's any
good or not?  If that's what you mean, I agree; that's one way
it could be considered "significant".

> >This is not because of optimization; this is because of the
> >language and style in which projects are implemented.  Now,
> >this is a significant debatable question.  Comparing the output
> >of optimizers is completely worthless to the central question
> >of whether REAL WORLD projects can be implement efficiently in
                                  ^^^^^^ [change to "will be"]
> >a particular language or not.
> 
> "can be" and "will be" are completely different questions.

Indeed.  I agree "will be" is a better question to ask.  In fact,
it's so much better that I hereby declare all my posts changed to
reflect the new wording. :-)

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@a-sis.com> writes:

>I would conclude that for that *specific* problem, the C compiler
>did a bad job of optimization.  As I frequently point out (and
>I frequently get abuse for it), optimizers are very imperfect
>beasts at best.

Well, it all depends on what you mean by a "bad" job of optimisation.
I actually tried several compilers, and the Sun C compiler was one
of the *best*.  If you call being 3rd out of 10 "a bad job", if you
call taken 1.2x the time of the very best but 0.2x the time of the
very worst "a bad job", then you have made your point.

>Do you doubt that if we brought the writers of the Sun compiler
>and had them fix their optimizer, they couldn't make it produce
>*exactly* the same code as the Ada compiler (or Fortran compiler,
>for that matter)?  Of course they could.

You are wrong.  Of *course* I doubt it, and so does anyone who understands
how compilers work.  Compilers have to respect the semantics of the
languages they compile.  They cannot take shortcuts that might produce
incorrect results.  Until the 'restrict' keyword is a standard part of C,
which it soon will be, but currently isn't, a C compiler will not be
*allowed* to pull the kinds of tricks that the Fortran compiler did in
this example.

>The real question that you refuse to come to terms with is, what
>is the average case over a large set of compilers over a large set
>of non-trivial programs over a large set of problem types?  And
>this is a very difficult question to answer.

I refuse to come to terms with it, because there can be no useful or
meaningful answer to it.  

 - tests over a wide range of problem types are of absolutely no
   interest to the person who started this thread; that person has
   ONE program and was considering converting from Ada to C.
   Suppose your impossible average were that Ada was 1.2 times
   faster than C.  Would that tell the person who has a specific
   problem whether to use Ada or C?  OF COURSE IT WOULDN'T.

 - tests over a wide range of compilers are of absolutely no interest.
   I can bias the results any way I want by insisting on the inclusion
   of enough bad compilers.  And the results are of no interest at all
   to the original poster who simply isn't concerned with _all_ Ada
   compilers or _all_ C compilers.  

 - insisting on a wide range of compilers is a profoundly dishonest
   thing for you to do.  My claim is that there is *one* free Ada
   compiler which in my admittedly limited experience routinely does
   as well as or better than the *best* C compiler I have available to
   me.  (Believe me, the Sun C compiler has a *good* optimiser, and if
   I were trying to develop graphics code exploiting the VIS opcodes
   I couldn't ask for a better.)  This fact *is* of interest to the
   poster who started the thread:  there is a *free* Ada compiler
   which does very well; it doesn't *MATTER* what other Ada compilers
   do.  I have been trying very hard to stick to the topic of this
   thread, which has nothing to do with whethere Ada is *always*
   better than C or not, but only with whether it would make
   economic sense to convert from Ada to C when there is a very good
   free Ada compiler.

 - tests over a large set of non-trivial programs would be of interest
   *in the general case*.  But I am concerned with the person who was
   thinking about converting *one* program to C.

   Again, you can get any results you want by insisting on suitably
   biassed programs.  There is a lot of seriously inefficient code
   out there.

Can you not get it through your head that I was not stating any
general proposition, but simply saying that I saw no obvious reason
why _one_ program should be converted from Ada to C, and giving a
*supporting example*?

>Your suggestion that comparing compilers on one platform for
>one program tells you something significant is laughable at
>best.

You may not think it significant that a free compiler for a robust
language outperforms a non-free compiler for a less expressive and
less robust but more popular one.  I do.  If you don't think the
obvious implication (get GNAT and try it on _your_ program and see
if you like the performance), then laugh away, but the laugh's on you.

>Sounds like it's a crappy C optimizer to me, especially considering
>the wide disparity between the C results and the other languages.

What "wide" disparity?  The smallest time in the set was 25 seconds.
The largest time was 141 seconds.  The C time was 30 seconds.  (And
to the best of my belief, it uses the *same* optimiser as the
Fortran compiler!)

The machine where I did the tests has been upgraded.  
    gcc -O6		14 seconds
    Sun cc -xO4		12 seconds
If you want to call the SPARCompiler optimiser "crappy", what words
will you find for the GCC one?

>*This* is a reasonable conclusion.

Your conclusion that the SPARCompiler C optimiser is "crappy"
is not a reasonable one.  *You* will have to provide some data if
you want to make _that_ claim.

>If you have bothered to write
>other programs in C and Ada, that would indicate to me that they
>were trivial algorithms, and therefore your conclusions invalid.

I see.  If someone *does* do head to head comparisons, they
are necessarily trivial and therefore invalid.

>Look at it this way; if I implement an algorithm in two languages,
>C and C++, and compare the results, they will probably be very
>similiar (if not identical).

The GCC compiler's output is as much slower on this platform as
the Sun C compiler's output is slower than the Sun Fortran 77 compiler's.
You called 20% a "wide disparity" and the sign of a "crappy" optimiser.
But there is as much difference between compilers for the *same*'
language as there is between good compilers for *different* languages.

Let this stand as a generalisation I *would* be prepared to defend:

   if a head to head comparison between compiler A for language X
   and compiler B for language Y on the platform of interest to you
   does not find a difference in excess of 20%, it is not worth
   your while converting from the _apparently_ slower language to
   the _apparently_ faster language.  (There are of course exceptions
   in embdedded and real-time programming.)

I can see no reason to expect C++ performance to be as good as C
performance in general.  Compiler writers have enough on their hands
trying to cope with an extremely complex language which has historically
been changing faster than compilers could keep up, I count it a miracle
when a C++ compiler generates _working_ code for a C++ program.

Let's just get a data point:
	cc	12 seconds		\ from Sun
	CC	13 seconds		/ from Sun (NOT cfront)
This is comparable to the difference I reported between C and Ada,
and it's the _same_ source file.

>However, let's take a very large
>project with two teams of people, and have 1 implement the project
>using C, and one implement it using C++.

As soon as you have a very large project, you have extremely great
variations between programmers.  As soon as you deal with C++, you
have to cope with immature compilers, severe porting problems, and
other problems.

>I have no formal study for this, but speaking to many people who
>have gone through the process, and reading a lot about many
>manager's experiences, I have heard a common theme: Projects
>implemented using OOP within the C++ language have experienced
>significant performance problems because of the overhead of class
>structures, heavy dependance on dynamic memory allocation, and the
>difficulty in designing good object classes.

I have no quarrel with this, except to note that
(a) it has absolutely no relevance to the originator of this thread,
    who was thinking of *converting* an existing Ada program to C.
    What would that do to performance, portability, and price of
    maintenance?  Those are relevant questions for this thread.

(b) you have only given us half the story:
	  Did not use OOP  Did use OOP
	+----------------+----------------+
    C	| Fewer problems |  ????????????  |
    C++ | ?????????????? | More problems  |
	+----------------+----------------+

    What about programs that used OOP in C?  It's often enough done.
    What about programs in C++ that didn't use OOP?  That's supposedly
    a selling point of C++, that it's a "better C".

>This is not because of optimization; this is because of the
>language and style in which projects are implemented.

Now _there_ is a non-sequitur, if ever there was one.  Can it be that
you are totally unaware of the work that has been done on link-time
optimisation of OOP programs to reduce the cost of dispatching?  (Not
only does this often eliminate dispatching, but that then enables
inlining, which permits more optimisations.)  As for the costs of
dynamic memory allocation, that can be extremely cheap, so why do
you think it might not be?  Are you unaware of the work on region-
based analysis?

As for the difficulty of designing good classes, good design is always
hard, but having conceded that, what is this supposed to tell the
originator of this thread, who was concerned about converting an
*EXISTING* program from Ada to C.  We have not been told whether it
used OOP or not, but if it did, any design has _already_ been done.

>Now, this is a significant debatable question.

What is?

- overhead of class structures?
  Compared with what?
  One of the *achieved* design goals of C++ is that you don't have any
  memory overheads compared with C if you don't explicitly ask for them.
  Such overheads as may exist depend a great deal on compiler technology.

- heavy dependence on dynamic memory allocation?
  But dynamic memory allocation can be very cheap.
  UNIX C malloc() implementations have traditionally been very expensive,
  unless you use mallopt().
  A *lot* of work has been done on reducing the costs of dynamic memory
  allocation, with excellent results, but you would dismiss this as
  compiler optimisation, and therefore as not worth talking about when
  it doesn't lead to the result you want.

  C++ has the notational resources to admit very efficient (but still
  "manual" and therefore not entirely trustworthy) memory management.
  
- difficulty of good design?
  What's to debate?  Of course it's hard, that's why design patterns
  and reuse libraries are so important.

>Comparing the output
>of optimizers is completely worthless to the central question
>of whether REAL WORLD projects can be implement efficiently in
>a particular language or not.

That may be *your* central question, but it was *not* the topic of
this thread.  Just to say it once again: the initial question was
about converting Ada to C, and my question was "why bother? is there
any reason to expect it to buy you anything? I don't think so."

Can real world projects be implemented efficiently in Ada?
Well, if you insist that anything I can write must be trivial and
my conclusions invalid, I shall have to leave that to other people
to answer.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<52q7lq$qqu@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@a-sis.com> writes:

> >Do you doubt that if we brought the writers of the Sun compiler
> >and had them fix their optimizer, they couldn't make it produce
> >*exactly* the same code as the Ada compiler (or Fortran compiler,
> >for that matter)?  Of course they could.
>
> You are wrong.  Of *course* I doubt it, and so does anyone who understands
> how compilers work.  Compilers have to respect the semantics of the
> languages they compile.  They cannot take shortcuts that might produce
> incorrect results.  Until the 'restrict' keyword is a standard part of C,
> which it soon will be, but currently isn't, a C compiler will not be
> *allowed* to pull the kinds of tricks that the Fortran compiler did in
> this example.

Well, now you throw in new information that the problem in question
was not able to be optimized due to constraints of the C language.
Of course, this is still not relevent to a large project that
presumably the original poster has.

> >The real question that you refuse to come to terms with is, what
> >is the average case over a large set of compilers over a large set
> >of non-trivial programs over a large set of problem types?  And
> >this is a very difficult question to answer.
> 
> I refuse to come to terms with it, because there can be no useful or
> meaningful answer to it.

Exactly.  So why do you think a specific case is any better?

[snip]
======================================
>  - tests over a large set of non-trivial programs would be of interest
>    *in the general case*.  But I am concerned with the person who was
>    thinking about converting *one* program to C.

>    Again, you can get any results you want by insisting on suitably
>    biassed programs.  There is a lot of seriously inefficient code
>    out there.

THANK YOU!  You make my point for me.  That's all I'm saying, and
that's all my original point said.  You can't make generalizations
about the fellow's large project based on one specific example.
=======================================

> Can you not get it through your head that I was not stating any
> general proposition, but simply saying that I saw no obvious reason
> why _one_ program should be converted from Ada to C, and giving a
> *supporting example*?

The point is that the supporting example is "profoundly
dishonest".  What was my only criticism of your post?  That
you can't make generalizations based on one example. *THAT'S ALL*
Just admit it was worthless, and this thread is over.

> >Your suggestion that comparing compilers on one platform for
> >one program tells you something significant is laughable at
> >best.
> 
> You may not think it significant that a free compiler for a robust
> language outperforms a non-free compiler for a less expressive and
> less robust but more popular one.  I do.  If you don't think the
> obvious implication (get GNAT and try it on _your_ program and see
> if you like the performance), then laugh away, but the laugh's on you.

It is certainly interesting for this one problem, but completely
worthless to the general question of whether the fellow would
gain anything from conversion of his source code.

> >Sounds like it's a crappy C optimizer to me, especially considering
> >the wide disparity between the C results and the other languages.
> 
> What "wide" disparity?  The smallest time in the set was 25 seconds.
> The largest time was 141 seconds.  The C time was 30 seconds.  (And
> to the best of my belief, it uses the *same* optimiser as the
> Fortran compiler!)
> 
> The machine where I did the tests has been upgraded.  
>     gcc -O6		14 seconds
>     Sun cc -xO4		12 seconds
> If you want to call the SPARCompiler optimiser "crappy", what words
> will you find for the GCC one?
> 
> >*This* is a reasonable conclusion.
> 
> Your conclusion that the SPARCompiler C optimiser is "crappy"
> is not a reasonable one.  *You* will have to provide some data if
> you want to make _that_ claim.

Well, perhaps crappy in this one case, unless (as you now point out)
the program was written such that the optimizer could not optimize
it due to constraints of the C language.

> >If you have bothered to write
> >other programs in C and Ada, that would indicate to me that they
> >were trivial algorithms, and therefore your conclusions invalid.
> 
> I see.  If someone *does* do head to head comparisons, they
> are necessarily trivial and therefore invalid.

No, if *you* have.  Since you haven't brought up any large-scale
comparisons, I have to conclude that you haven't done any.  If
there are any large-scale project comparisons, they may be valid.

> >Look at it this way; if I implement an algorithm in two languages,
> >C and C++, and compare the results, they will probably be very
> >similiar (if not identical).
[snip long-winded criticism of this statement]

You are overgeneralizing my statement.  My only point is that they
share enough in common that if I implement an algorithm, i.e., a
small program v.s. a large project (which I admit I didn't state
clearly enough), it will probably get about the same results given
similiarly good compilers.

This was only meant to be a lead-in into ...

> >However, let's take a very large
> >project with two teams of people, and have 1 implement the project
> >using C, and one implement it using C++.
> 
> As soon as you have a very large project, you have extremely great
> variations between programmers.  As soon as you deal with C++, you
> have to cope with immature compilers, severe porting problems, and
> other problems.

Well, we have to assume a staff of equal competence and equal
technology in their respective languages.  

> >I have no formal study for this, but speaking to many people who
> >have gone through the process, and reading a lot about many
> >manager's experiences, I have heard a common theme: Projects
> >implemented using OOP within the C++ language have experienced
> >significant performance problems because of the overhead of class
> >structures, heavy dependance on dynamic memory allocation, and the
> >difficulty in designing good object classes.
> 
> I have no quarrel with this, except to note that
> (a) it has absolutely no relevance to the originator of this thread,
>     who was thinking of *converting* an existing Ada program to C.
>     What would that do to performance, portability, and price of
>     maintenance?  Those are relevant questions for this thread.

This is *extremely* relevent!  The point is that even though C++
shares a lot of C's roots, C++ can have scaling problems on real-
world projects.  Does Ada have the same problems?  I DON'T KNOW!
All I know is that you can't prove one way or the other based on
small test programs in a single environment.

> (b) you have only given us half the story:
> 
>     What about programs that used OOP in C?  It's often enough done.
>     What about programs in C++ that didn't use OOP?  That's supposedly
>     a selling point of C++, that it's a "better C".

Well, what about it?  You can ask "what ifs" all day long.  Yes,
it's possible to have efficient OOP programs, just as it's
possible to have readable APL programs.  The questions are, how
hard is it to make an efficient OOP program, is it worth the
additional design cost, and how often do you *still* get a mess
even taking all that into account?  My point is that based on
admittedly anecdotal evidence, it is *extremely* difficult to
get to a balance between good class structures and efficient
class structures, and some mighty big disasters have been wrought
from people who have guessed wrong.

> >This is not because of optimization; this is because of the
> >language and style in which projects are implemented.
> 
> Now _there_ is a non-sequitur, if ever there was one.  Can it be that
> you are totally unaware of the work that has been done on link-time
> optimisation of OOP programs to reduce the cost of dispatching?  (Not
> only does this often eliminate dispatching, but that then enables
> inlining, which permits more optimisations.)  As for the costs of
> dynamic memory allocation, that can be extremely cheap, so why do
> you think it might not be?  Are you unaware of the work on region-
> based analysis?

You live in the ivory tower; I live in the real world.  You may want
to come out and get some fresh air once in a while.  If technology
comes along such that these problems get solved, then I will
embrace it.  Until then, why destroy my products in the name of
"progress"?

> As for the difficulty of designing good classes, good design is always
> hard, but having conceded that, what is this supposed to tell the
> originator of this thread, who was concerned about converting an
> *EXISTING* program from Ada to C.  We have not been told whether it
> used OOP or not, but if it did, any design has _already_ been done.
> 
> >Now, this is a significant debatable question.
> 
> What is?
> 
> - overhead of class structures?
>   Compared with what?
>   One of the *achieved* design goals of C++ is that you don't have any
>   memory overheads compared with C if you don't explicitly ask for them.
>   Such overheads as may exist depend a great deal on compiler technology.

"If you don't ask for them".
"Depend a great deal on compiler technology".

So, in other words, to be efficient, I have to be extremely careful
about what I use and what I don't use, and my portability is limited
"a great deal" by the compiler.  Again, and admittedly anecdotal,
real world experience does not back up your claims.  Maybe it will
someday.

> - heavy dependence on dynamic memory allocation?
>   But dynamic memory allocation can be very cheap.
>   UNIX C malloc() implementations have traditionally been very expensive,
>   unless you use mallopt().
>   A *lot* of work has been done on reducing the costs of dynamic memory
>   allocation, with excellent results, but you would dismiss this as
>   compiler optimisation, and therefore as not worth talking about when
>   it doesn't lead to the result you want.
> 
>   C++ has the notational resources to admit very efficient (but still
>   "manual" and therefore not entirely trustworthy) memory management.

Theoretically this may all be true.  In the real world, as far as I
can see, it has not happened that way.

> - difficulty of good design?
>   What's to debate?  Of course it's hard, that's why design patterns
>   and reuse libraries are so important.

Design is always difficult, but class design appears to be particularly
difficult to get right.

> >Comparing the output
> >of optimizers is completely worthless to the central question
> >of whether REAL WORLD projects can be implement efficiently in
> >a particular language or not.
> 
> That may be *your* central question, but it was *not* the topic of
> this thread.  Just to say it once again: the initial question was
> about converting Ada to C, and my question was "why bother? is there
> any reason to expect it to buy you anything? I don't think so."

What do you think the topic of the thread is?  You tried to show
that converting his Ada code was not a good idea, and gave a
specific example to try and show that Ada is not always slower
than C.  I pointed out that you can't make generalizations based
on one example.  Your central point is fine; I only take exception
to using one small example to make the point.

If you had only said, "based on my experience, Ada has proven to
be comparably efficient to C", I would not have had a problem
with it.  The difference is the latter statement is making an
opinion based on a base of experience, but your original statement
made an opinion based on a specific example, which is invalid.

> Can real world projects be implemented efficiently in Ada?
> Well, if you insist that anything I can write must be trivial and
> my conclusions invalid, I shall have to leave that to other people
> to answer.

-SIGH- read back what I said, and don't overgeneralize.

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Ian Ward]

In article 87ee6fce@timpent.a-sis.com, "Tim Behrendsen" <tim@a-sis.com> () writes:
>
>Well, now you throw in new information that the problem in question
>was not able to be optimized due to constraints of the C language.
>Of course, this is still not relevent to a large project that
>presumably the original poster has.
>

Can I ask, are you agreeing with Richard here that, because of the
flexibility of "C"'s semantics, "C" compilers have a more difficult
optimisation task. (Or are you disagreeing.)

>> >The real question that you refuse to come to terms with is, what
>> >is the average case over a large set of compilers over a large set
>> >of non-trivial programs over a large set of problem types?  And
>> >this is a very difficult question to answer.
>> 

This is very difficult, noone I know has ever done this experiment.
I guess this is because it involves spending a lot of money.

>
>No, if *you* have.  Since you haven't brought up any large-scale
>comparisons, I have to conclude that you haven't done any.  If
>there are any large-scale project comparisons, they may be valid.
>

It is very difficult to do large scale comparisons, there are only
two of which I know. The first is the well documented case by
? Dr. Stephen Ziegler ? (apologies if the name is incorrect.)

The second is the Boeing 777 flight software, where three separate
projects (which was a really good idea,) were started to implement
the software, one in "C", one in PL1, and one in Ada. The problem
with comparing these languages in this situation was that a. Ada 
was designed for writing big, and reliable, and embedded systems.
Therefore it is unlikely that "C" was ever going to be at the 
same stage of development to make sensible comparions. (In fact,
that is exactly what happened, Byte described the projects of having
"nuisance disconnects" which was the politically sensitive way of
describing something else.) The end result was that "C" was being
used for something it was not designed for, and understandably it
was coping no better than it could have reasonably been expected
to have. Thus it was canned, as was the PL1. (This is my
interpretation of the printed word.)

>
>> Now _there_ is a non-sequitur, if ever there was one.  Can it be that
>> you are totally unaware of the work that has been done on link-time
>> optimisation of OOP programs to reduce the cost of dispatching?  (Not
>> only does this often eliminate dispatching, but that then enables
>> inlining, which permits more optimisations.)  As for the costs of
>> dynamic memory allocation, that can be extremely cheap, so why do
>> you think it might not be?  Are you unaware of the work on region-
>> based analysis?
>
>You live in the ivory tower; I live in the real world.  You may want
>to come out and get some fresh air once in a while.  If technology
>comes along such that these problems get solved, then I will
>embrace it.  Until then, why destroy my products in the name of
>"progress"?
>

It am sure that if (at least) GNU Ada decides that a dispatch can
be worked out at compile time, as it often can, then more likely than
not, it will do a direct call instead. This one optimisation I 
already know about, and I don't really know anything about the subject.
So I have to go with the ivory tower here. Compilers (all compilers)
really have come on, there are few low-level programmers that can
now keep up with them (even given the five or six hundred thousand
million times slower they are at writing assembler.)


>
>-- Tim Behrendsen (tim@a-sis.com)


Best regards,
Ian.
---
Ian Ward's opinions only : wardi@rsd.bel.alcatel.be

Re: Ada to C/C++ translator needed

[Tim Behrendsen]

Ian Ward <wardi@rsd.bel.alcatel.be> wrote in article
<52ttll$351@btmpjg.god.bel.alcatel.be>...
> In article 87ee6fce@timpent.a-sis.com, "Tim Behrendsen" <tim@a-sis.com> () writes:
> >
> >Well, now you throw in new information that the problem in question
> >was not able to be optimized due to constraints of the C language.
> >Of course, this is still not relevent to a large project that
> >presumably the original poster has.
> 
> Can I ask, are you agreeing with Richard here that, because of the
> flexibility of "C"'s semantics, "C" compilers have a more difficult
> optimisation task. (Or are you disagreeing.)

I agree with this.  This topic has flamed up so much from my
original simple assertion.  All I'm saying is that general
conclusions on the efficiency of a large project in different
languages can't be made from small test cases, particularly
numerical algorithms.

> >> >The real question that you refuse to come to terms with is, what
> >> >is the average case over a large set of compilers over a large set
> >> >of non-trivial programs over a large set of problem types?  And
> >> >this is a very difficult question to answer.
> >> 
> 
> This is very difficult, noone I know has ever done this experiment.
> I guess this is because it involves spending a lot of money.

And a lot of time, and even then the results are open to
interpretation.  This is why small specific examples implemented
into various languages do not give very much general purpose
information applicable to large projects.

> >No, if *you* have.  Since you haven't brought up any large-scale
> >comparisons, I have to conclude that you haven't done any.  If
> >there are any large-scale project comparisons, they may be valid.
> >
> 
> It is very difficult to do large scale comparisons, there are only
> two of which I know. The first is the well documented case by
> ? Dr. Stephen Ziegler ? (apologies if the name is incorrect.)
> 
> The second is the Boeing 777 flight software, where three separate
> projects (which was a really good idea,) were started to implement
> the software, one in "C", one in PL1, and one in Ada. The problem
> with comparing these languages in this situation was that a. Ada 
> was designed for writing big, and reliable, and embedded systems.
> Therefore it is unlikely that "C" was ever going to be at the 
> same stage of development to make sensible comparions. (In fact,
> that is exactly what happened, Byte described the projects of having
> "nuisance disconnects" which was the politically sensitive way of
> describing something else.) The end result was that "C" was being
> used for something it was not designed for, and understandably it
> was coping no better than it could have reasonably been expected
> to have. Thus it was canned, as was the PL1. (This is my
> interpretation of the printed word.)

I agree it is very difficult to make comparisons, which is why
we have to go anecdotal evidence such as these.  And it would
seem that they only made bug analysis comparisons rather than
performance comparisons (unless there was more to the article
than you are quoting).

To tell you the truth, I am reaching a stage in my programming
"maturity" to where I would be willing to give up some efficiency
for safety (within limits, of course).  Perhaps I won't have to
as compiler technology improves.

> >>[snip: lots of work in improving dispatching; dynamic mem alloc]
> >
> >You live in the ivory tower; I live in the real world.  You may want
> >to come out and get some fresh air once in a while.  If technology
> >comes along such that these problems get solved, then I will
> >embrace it.  Until then, why destroy my products in the name of
> >"progress"?
> 
> It am sure that if (at least) GNU Ada decides that a dispatch can
> be worked out at compile time, as it often can, then more likely than
> not, it will do a direct call instead. This one optimisation I 
> already know about, and I don't really know anything about the subject.
> So I have to go with the ivory tower here. Compilers (all compilers)
> really have come on, there are few low-level programmers that can
> now keep up with them (even given the five or six hundred thousand
> million times slower they are at writing assembler.)

I admit that compiler technology has been improving in recent years,
and will continue to improve.  I have been burned before by new
technology that ended up being dead ends, so I am somewhat cautious
when it comes to embracing the latest fads.  "The pioneers take the
arrows.  It's the people that follow the pioneers that build the
cities."  This is how I see OOP, as an example.  There is so much
admittedly anecdotal evidence of OOP performance disasters that I
take a very wait-and-see attitude.  It's all well and good if there
are solutions in the pipeline, but until I have an IBM part number
for AIX, it doesn't do me much good.

-- Tim Behrendsen (tim@a-sis.com)

Re: Ada to C/C++ translator needed

[Tanmoy Bhattacharya]

fred@genesis.demon.co.uk (Lawrence Kirby) writes:
<snip>
> >>       static int i = 1 ? 1 : (++j);
<snip>
> >Fair enough, given an appropriate declaration for j,
> >this line gets through
<snip>
> >Evidently, by your argument, I haven't _got_ any C compilers to test!

One usually talks about any real shadow of a platonic ideals :-)

> Possibly, but you haven't proved it. You have to consider 6.4:
> 
> "An implementation may accept other forms of constant expression"
<snip>

Not quite. It is still not allowed to violate constraints (This came
up in the discussion about `char a[1?1:(0,0)]' or some such
meaningless example in comp.std.c). j++ in a constant expression is a
violation of a constraint and must be diagnosed. 

The quoted phrase may be used to declare, for example, that a `const
qualified non-volatile object initialized by a constant expression is
a constant expression wherever the declaration initializng it is
visible' (as a poster no doubt meant in a thread in c.l.c.m) in a
particular implementation.

Cheers
Tanmoy
-- 
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

Re: Ada to C/C++ translator needed

[Lawrence Kirby]

In article <y8rancyr0n.fsf@qcd.lanl.gov>
           tanmoy@qcd.lanl.gov "Tanmoy Bhattacharya" writes:

>Not quite. It is still not allowed to violate constraints (This came
>up in the discussion about `char a[1?1:(0,0)]' or some such
>meaningless example in comp.std.c). j++ in a constant expression is a
>violation of a constraint and must be diagnosed. 

I'm sure you're right but which constraint does it violate?

>The quoted phrase may be used to declare, for example, that a `const
>qualified non-volatile object initialized by a constant expression is
>a constant expression wherever the declaration initializng it is
>visible' (as a poster no doubt meant in a thread in c.l.c.m) in a
>particular implementation.

So, a devious backdoor to C++.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Ada to C/C++ translator needed

[Peter Seebach]

In article <844636753snz@genesis.demon.co.uk>,
Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>In article <y8rancyr0n.fsf@qcd.lanl.gov>
>           tanmoy@qcd.lanl.gov "Tanmoy Bhattacharya" writes:
>>Not quite. It is still not allowed to violate constraints (This came
>>up in the discussion about `char a[1?1:(0,0)]' or some such
>>meaningless example in comp.std.c). j++ in a constant expression is a
>>violation of a constraint and must be diagnosed. 

>I'm sure you're right but which constraint does it violate?

6.4 says that constant expressions *must not contain* certain operators,
including increment, decrement, comma, function call, and my memory fails
to suggest the others.

(And some section requires array sizes, and another requires initializers
for static objects, to be constants.)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

Re: Ada to C/C++ translator needed

[Tanmoy Bhattacharya]

fred@genesis.demon.co.uk (Lawrence Kirby) writes:

> 
> In article <y8rancyr0n.fsf@qcd.lanl.gov>
>            tanmoy@qcd.lanl.gov "Tanmoy Bhattacharya" writes:
> 
> >Not quite. It is still not allowed to violate constraints (This came
> >up in the discussion about `char a[1?1:(0,0)]' or some such
> >meaningless example in comp.std.c). j++ in a constant expression is a
> >violation of a constraint and must be diagnosed. 
> 
> I'm sure you're right but which constraint does it violate?
> 

6.4 Constraint: 

"Constant expressions shall not contain assignment, increment,
 decrement, function-call, or comma operators, except when they are
 contained within the operand of a sizeof operator.

 Each constant expression shall evaluate to a constant that is in the
 range of representable values of its type."

Note that it does not forbid use of contents of objects (that is in
the semantics section), but it does forbid operators that change the
values of objects, operators that invoke separate body of code, and
the comma operator. Incidentally, assignment operators include
(6.3.16) both the simple assignment operator =, and also the compound
forms like += etc.; and hence all of these are forbidden.

The semantics section forbids a lot more (e.g. using floating point
arithmetic if the final answer is integral, using pointers except
within sizeof if the final answer is arithmetic, accessing the value
of an object etc.)

Cheers
Tanmoy
-- 
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

Re: Ada to C/C++ translator needed

[Simon Johnston]

> You are wrong.  Of *course* I doubt it, and so does anyone who understands
> how compilers work.  Compilers have to respect the semantics of the
> languages they compile.  They cannot take shortcuts that might produce
> incorrect results.  Until the 'restrict' keyword is a standard part of C,
> which it soon will be, but currently isn't, a C compiler will not be
> *allowed* to pull the kinds of tricks that the Fortran compiler did in
> this example.

"restrict" what is this new keyword, where can one find out about this!

Re: Ada to C/C++ translator needed

[Richard Riehle]

On Wed, 2 Oct 1996, Simon Johnston wrote:

> "restrict" what is this new keyword, where can one find out about this!

  I think he may be referring to #define Strict which is available
  on some C/C++ compilers to enforce type checking.

  Richard Riehle

Re: Ada to C/C++ translator needed

[Richard A. O'Keefe]

I mentioned the proposed 'restrict' keyword.

On Wed, 2 Oct 1996, Simon Johnston wrote:

> "restrict" what is this new keyword, where can one find out about this!

Richard Riehle <rriehle@nunic.nu.edu> writes:

>  I think he may be referring to #define Strict which is available
>  on some C/C++ compilers to enforce type checking.

Richard Riehle is wrong.  I am referring to the proposed C9x keyword
'restrict'.  It is the cleaned up and redesigned replacement for the
'noalias' keyword added at the last minute to C89 and dropped at the
last second.  To put it at its very crudest,

	void vecadd(float a[restrict],
		    float const b[restrict],
		    float const c[restrict], int n) {
	    int i;
	    for (i = 0; i < n; i++) a[i] = b[i] + c[i];
	}

tells a compiler that there is no aliasing amongst a, b, and c,
so that it doesn't have to follow the strict sequential model.
It can, for example, do
	ldf4  f0, b		- quad-word FP load
	addi  #16,b
	ldf4  f4, c
	addi  #16,c
	addf  f0, f4, f0	- S.P. FP add
	addf  f1, f5, f1
	addf  f2, f6, f2
	addf  f3, f7, f3
	stf4  f0, a				 
	addi  #16,a
inside a loop, which would _not_ give the right results if for example
a == &b[1].  On a modern superscalar RISC, this might end up taking n
cycles, whereas maintaining C semantics in the face of possible aliasing
would probably take 3n cycles.  I have something rather like the
UltraSPARC in mind, but don't mistake this for UltraSPARC code.  And you
would need loop unrolling and good scheduling to reach that 1 cycle per
FLOP result.  This kind of speedup is why noalias was wanted, and as a
tamed noalias, restrict is going to be important.

The proposal has been available over the net for enough years that I have
forgotten exactly where I got it.  It is _supported_ by one of the
compilers I use.  (Which is why that compiler is a very good compiler for
numerical performance experiments, contrary to one Tim Behrendsen's
attacks on it.)

Since this is comp.lang.ada, perhaps someone could explain clearly
whether an Ada compiler is allowed to perform this kind of optimisation
given

	type Vector is array (Positive range <>) of Float;

	procedure Vec_Add(A: out Vector; B, C: in Vector) is
	begin
	    for I in A'Range loop A(I) := B(I) + C(I); end loop;
	end Vec_Add;

I used to think that calls like

	declare
	    X, Y: Vector(3) := (1..3 => 1.0);
	begin
	    Vec_Add(X(2..3), X(1..2), Y(1..2));
	end;

were forbidden, because the result depended on whether 'in Vector' was
passed by copy or reference, but I probably got that wrong, and I am
even less sure of exactly what the rule is in Ada 95.  A factor of 3
speedup is worth having...

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada to C/C++ translator needed

[Tucker Taft]

Richard A. O'Keefe (ok@goanna.cs.rmit.edu.au) wrote:
: ...
: Since this is comp.lang.ada, perhaps someone could explain clearly
: whether an Ada compiler is allowed to perform this kind of optimisation
: given

: 	type Vector is array (Positive range <>) of Float;

: 	procedure Vec_Add(A: out Vector; B, C: in Vector) is
: 	begin
: 	    for I in A'Range loop A(I) := B(I) + C(I); end loop;
: 	end Vec_Add;

: I used to think that calls like

: 	declare
: 	    X, Y: Vector(3) := (1..3 => 1.0);
: 	begin
: 	    Vec_Add(X(2..3), X(1..2), Y(1..2));
: 	end;

: were forbidden, because the result depended on whether 'in Vector' was
: passed by copy or reference, but I probably got that wrong, and I am
: even less sure of exactly what the rule is in Ada 95.  A factor of 3
: speedup is worth having...

The rules regarding aliasing between parameters are given in RM95-6.2(12).
The generated code is allowed to result in the reading of an "old" value 
if there is aliasing between the parameters, and the code as written
would imply a write of an object by one access path followed by a read of 
the object by some other access path.  This implies that a loop
may be unrolled, and then different iterations interleaved by moving
certain of the reads earlier.

: Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA