* Ada to C/C++ translator needed @ 1996-09-25 0:00 Emmanuel Champommier 1996-09-25 0:00 ` David Weller 1996-09-26 0:00 ` Ian Ward 0 siblings, 2 replies; 46+ messages in thread From: Emmanuel Champommier @ 1996-09-25 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-25 0:00 Ada to C/C++ translator needed Emmanuel Champommier @ 1996-09-25 0:00 ` David Weller 1996-10-02 0:00 ` B|rje Norden 1996-10-07 0:00 ` Erik Magnuson 1996-09-26 0:00 ` Ian Ward 1 sibling, 2 replies; 46+ messages in thread From: David Weller @ 1996-09-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-25 0:00 ` David Weller @ 1996-10-02 0:00 ` B|rje Norden 1996-10-04 0:00 ` David Weller 1996-10-05 0:00 ` Robert Dewar 1996-10-07 0:00 ` Erik Magnuson 1 sibling, 2 replies; 46+ messages in thread From: B|rje Norden @ 1996-10-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-02 0:00 ` B|rje Norden @ 1996-10-04 0:00 ` David Weller 1996-10-05 0:00 ` Robert Dewar 1 sibling, 0 replies; 46+ messages in thread From: David Weller @ 1996-10-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-02 0:00 ` B|rje Norden 1996-10-04 0:00 ` David Weller @ 1996-10-05 0:00 ` Robert Dewar 1996-10-05 0:00 ` Frank Manning 1 sibling, 1 reply; 46+ messages in thread From: Robert Dewar @ 1996-10-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-05 0:00 ` Robert Dewar @ 1996-10-05 0:00 ` Frank Manning 1996-10-06 0:00 ` Samuel Tardieu 1996-10-07 0:00 ` Robert Dewar 0 siblings, 2 replies; 46+ messages in thread From: Frank Manning @ 1996-10-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-05 0:00 ` Frank Manning @ 1996-10-06 0:00 ` Samuel Tardieu 1996-10-07 0:00 ` Richard Kenner 1996-10-07 0:00 ` Robert Dewar 1 sibling, 1 reply; 46+ messages in thread From: Samuel Tardieu @ 1996-10-06 0:00 UTC (permalink / raw) To: Frank Manning >>>>> "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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-06 0:00 ` Samuel Tardieu @ 1996-10-07 0:00 ` Richard Kenner 1996-10-07 0:00 ` Robert Dewar 1996-10-08 0:00 ` Stephen Leake 0 siblings, 2 replies; 46+ messages in thread From: Richard Kenner @ 1996-10-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-07 0:00 ` Richard Kenner @ 1996-10-07 0:00 ` Robert Dewar 1996-10-08 0:00 ` Stephen Leake 1 sibling, 0 replies; 46+ messages in thread From: Robert Dewar @ 1996-10-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-07 0:00 ` Richard Kenner 1996-10-07 0:00 ` Robert Dewar @ 1996-10-08 0:00 ` Stephen Leake 1 sibling, 0 replies; 46+ messages in thread From: Stephen Leake @ 1996-10-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-05 0:00 ` Frank Manning 1996-10-06 0:00 ` Samuel Tardieu @ 1996-10-07 0:00 ` Robert Dewar 1996-10-08 0:00 ` Frank Manning 1 sibling, 1 reply; 46+ messages in thread From: Robert Dewar @ 1996-10-07 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-07 0:00 ` Robert Dewar @ 1996-10-08 0:00 ` Frank Manning 0 siblings, 0 replies; 46+ messages in thread From: Frank Manning @ 1996-10-08 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-25 0:00 ` David Weller 1996-10-02 0:00 ` B|rje Norden @ 1996-10-07 0:00 ` Erik Magnuson 1 sibling, 0 replies; 46+ messages in thread From: Erik Magnuson @ 1996-10-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-25 0:00 Ada to C/C++ translator needed Emmanuel Champommier 1996-09-25 0:00 ` David Weller @ 1996-09-26 0:00 ` Ian Ward 1996-10-02 0:00 ` Jon S Anthony ` (2 more replies) 1 sibling, 3 replies; 46+ messages in thread From: Ian Ward @ 1996-09-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-26 0:00 ` Ian Ward @ 1996-10-02 0:00 ` Jon S Anthony 1996-10-02 0:00 ` Jon S Anthony [not found] ` <52feul$os2@goanna.cs.rmit.edu.au> 2 siblings, 0 replies; 46+ messages in thread From: Jon S Anthony @ 1996-10-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-26 0:00 ` Ian Ward 1996-10-02 0:00 ` Jon S Anthony @ 1996-10-02 0:00 ` Jon S Anthony [not found] ` <52feul$os2@goanna.cs.rmit.edu.au> 2 siblings, 0 replies; 46+ messages in thread From: Jon S Anthony @ 1996-10-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
[parent not found: <52feul$os2@goanna.cs.rmit.edu.au>]
* Re: Ada to C/C++ translator needed [not found] ` <52feul$os2@goanna.cs.rmit.edu.au> @ 1996-09-28 0:00 ` Tim Behrendsen 1996-09-29 0:00 ` Ken Pizzini 1996-09-30 0:00 ` Richard A. O'Keefe 1996-10-06 0:00 ` Tanmoy Bhattacharya 1996-10-07 0:00 ` Tanmoy Bhattacharya 2 siblings, 2 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-09-28 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-28 0:00 ` Tim Behrendsen @ 1996-09-29 0:00 ` Ken Pizzini 1996-09-29 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Richard A. O'Keefe 1 sibling, 1 reply; 46+ messages in thread From: Ken Pizzini @ 1996-09-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-29 0:00 ` Ken Pizzini @ 1996-09-29 0:00 ` Tim Behrendsen 1996-09-29 0:00 ` Robert Dewar 1996-09-30 0:00 ` Richard A. O'Keefe 0 siblings, 2 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-09-29 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-29 0:00 ` Tim Behrendsen @ 1996-09-29 0:00 ` Robert Dewar 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Richard A. O'Keefe 1 sibling, 1 reply; 46+ messages in thread From: Robert Dewar @ 1996-09-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-29 0:00 ` Robert Dewar @ 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Matthew Heaney ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-09-30 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Tim Behrendsen @ 1996-09-30 0:00 ` Matthew Heaney 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` William Clodius 1996-10-01 0:00 ` Richard A. O'Keefe 2 siblings, 1 reply; 46+ messages in thread From: Matthew Heaney @ 1996-09-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Matthew Heaney @ 1996-09-30 0:00 ` Tim Behrendsen 0 siblings, 0 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-09-30 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Matthew Heaney @ 1996-09-30 0:00 ` William Clodius 1996-10-01 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 46+ messages in thread From: William Clodius @ 1996-09-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Matthew Heaney 1996-09-30 0:00 ` William Clodius @ 1996-10-01 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 46+ messages in thread From: Richard A. O'Keefe @ 1996-10-01 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-29 0:00 ` Tim Behrendsen 1996-09-29 0:00 ` Robert Dewar @ 1996-09-30 0:00 ` Richard A. O'Keefe 1996-09-30 0:00 ` Tim Behrendsen 1 sibling, 1 reply; 46+ messages in thread From: Richard A. O'Keefe @ 1996-09-30 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Richard A. O'Keefe @ 1996-09-30 0:00 ` Tim Behrendsen 0 siblings, 0 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-09-30 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-28 0:00 ` Tim Behrendsen 1996-09-29 0:00 ` Ken Pizzini @ 1996-09-30 0:00 ` Richard A. O'Keefe 1996-09-30 0:00 ` Peter Seebach 1996-09-30 0:00 ` Tim Behrendsen 1 sibling, 2 replies; 46+ messages in thread From: Richard A. O'Keefe @ 1996-09-30 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Richard A. O'Keefe @ 1996-09-30 0:00 ` Peter Seebach 1996-10-02 0:00 ` Richard A. O'Keefe 1996-09-30 0:00 ` Tim Behrendsen 1 sibling, 1 reply; 46+ messages in thread From: Peter Seebach @ 1996-09-30 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Peter Seebach @ 1996-10-02 0:00 ` Richard A. O'Keefe 1996-10-05 0:00 ` Lawrence Kirby 0 siblings, 1 reply; 46+ messages in thread From: Richard A. O'Keefe @ 1996-10-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-02 0:00 ` Richard A. O'Keefe @ 1996-10-05 0:00 ` Lawrence Kirby 0 siblings, 0 replies; 46+ messages in thread From: Lawrence Kirby @ 1996-10-05 0:00 UTC (permalink / raw) 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 ----------------------------------------- ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Richard A. O'Keefe 1996-09-30 0:00 ` Peter Seebach @ 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Peter Seebach 1996-10-01 0:00 ` Richard A. O'Keefe 1 sibling, 2 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-09-30 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Tim Behrendsen @ 1996-09-30 0:00 ` Peter Seebach 1996-09-30 0:00 ` Tim Behrendsen 1996-10-01 0:00 ` Richard A. O'Keefe 1 sibling, 1 reply; 46+ messages in thread From: Peter Seebach @ 1996-09-30 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Peter Seebach @ 1996-09-30 0:00 ` Tim Behrendsen 0 siblings, 0 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-09-30 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Peter Seebach @ 1996-10-01 0:00 ` Richard A. O'Keefe 1996-10-01 0:00 ` Tim Behrendsen 1 sibling, 1 reply; 46+ messages in thread From: Richard A. O'Keefe @ 1996-10-01 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-01 0:00 ` Richard A. O'Keefe @ 1996-10-01 0:00 ` Tim Behrendsen 1996-10-02 0:00 ` Ian Ward 0 siblings, 1 reply; 46+ messages in thread From: Tim Behrendsen @ 1996-10-01 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-01 0:00 ` Tim Behrendsen @ 1996-10-02 0:00 ` Ian Ward 1996-10-02 0:00 ` Tim Behrendsen 0 siblings, 1 reply; 46+ messages in thread From: Ian Ward @ 1996-10-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-02 0:00 ` Ian Ward @ 1996-10-02 0:00 ` Tim Behrendsen 0 siblings, 0 replies; 46+ messages in thread From: Tim Behrendsen @ 1996-10-02 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed [not found] ` <52feul$os2@goanna.cs.rmit.edu.au> 1996-09-28 0:00 ` Tim Behrendsen @ 1996-10-06 0:00 ` Tanmoy Bhattacharya 1996-10-06 0:00 ` Lawrence Kirby 1996-10-07 0:00 ` Tanmoy Bhattacharya 2 siblings, 1 reply; 46+ messages in thread From: Tanmoy Bhattacharya @ 1996-10-06 0:00 UTC (permalink / raw) 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 ] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-06 0:00 ` Tanmoy Bhattacharya @ 1996-10-06 0:00 ` Lawrence Kirby 1996-10-08 0:00 ` Peter Seebach 0 siblings, 1 reply; 46+ messages in thread From: Lawrence Kirby @ 1996-10-06 0:00 UTC (permalink / raw) 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 ----------------------------------------- ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-06 0:00 ` Lawrence Kirby @ 1996-10-08 0:00 ` Peter Seebach 0 siblings, 0 replies; 46+ messages in thread From: Peter Seebach @ 1996-10-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed [not found] ` <52feul$os2@goanna.cs.rmit.edu.au> 1996-09-28 0:00 ` Tim Behrendsen 1996-10-06 0:00 ` Tanmoy Bhattacharya @ 1996-10-07 0:00 ` Tanmoy Bhattacharya 2 siblings, 0 replies; 46+ messages in thread From: Tanmoy Bhattacharya @ 1996-10-07 0:00 UTC (permalink / raw) 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 ] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed
@ 1996-10-02 0:00 Simon Johnston
1996-10-07 0:00 ` Richard Riehle
0 siblings, 1 reply; 46+ messages in thread
From: Simon Johnston @ 1996-10-02 0:00 UTC (permalink / raw)
> 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!
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-02 0:00 Simon Johnston @ 1996-10-07 0:00 ` Richard Riehle 1996-10-09 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 46+ messages in thread From: Richard Riehle @ 1996-10-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-07 0:00 ` Richard Riehle @ 1996-10-09 0:00 ` Richard A. O'Keefe 1996-10-15 0:00 ` Tucker Taft 0 siblings, 1 reply; 46+ messages in thread From: Richard A. O'Keefe @ 1996-10-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Ada to C/C++ translator needed 1996-10-09 0:00 ` Richard A. O'Keefe @ 1996-10-15 0:00 ` Tucker Taft 0 siblings, 0 replies; 46+ messages in thread From: Tucker Taft @ 1996-10-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~1996-10-15 0:00 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-09-25 0:00 Ada to C/C++ translator needed Emmanuel Champommier 1996-09-25 0:00 ` David Weller 1996-10-02 0:00 ` B|rje Norden 1996-10-04 0:00 ` David Weller 1996-10-05 0:00 ` Robert Dewar 1996-10-05 0:00 ` Frank Manning 1996-10-06 0:00 ` Samuel Tardieu 1996-10-07 0:00 ` Richard Kenner 1996-10-07 0:00 ` Robert Dewar 1996-10-08 0:00 ` Stephen Leake 1996-10-07 0:00 ` Robert Dewar 1996-10-08 0:00 ` Frank Manning 1996-10-07 0:00 ` Erik Magnuson 1996-09-26 0:00 ` Ian Ward 1996-10-02 0:00 ` Jon S Anthony 1996-10-02 0:00 ` Jon S Anthony [not found] ` <52feul$os2@goanna.cs.rmit.edu.au> 1996-09-28 0:00 ` Tim Behrendsen 1996-09-29 0:00 ` Ken Pizzini 1996-09-29 0:00 ` Tim Behrendsen 1996-09-29 0:00 ` Robert Dewar 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Matthew Heaney 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` William Clodius 1996-10-01 0:00 ` Richard A. O'Keefe 1996-09-30 0:00 ` Richard A. O'Keefe 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Richard A. O'Keefe 1996-09-30 0:00 ` Peter Seebach 1996-10-02 0:00 ` Richard A. O'Keefe 1996-10-05 0:00 ` Lawrence Kirby 1996-09-30 0:00 ` Tim Behrendsen 1996-09-30 0:00 ` Peter Seebach 1996-09-30 0:00 ` Tim Behrendsen 1996-10-01 0:00 ` Richard A. O'Keefe 1996-10-01 0:00 ` Tim Behrendsen 1996-10-02 0:00 ` Ian Ward 1996-10-02 0:00 ` Tim Behrendsen 1996-10-06 0:00 ` Tanmoy Bhattacharya 1996-10-06 0:00 ` Lawrence Kirby 1996-10-08 0:00 ` Peter Seebach 1996-10-07 0:00 ` Tanmoy Bhattacharya -- strict thread matches above, loose matches on Subject: below -- 1996-10-02 0:00 Simon Johnston 1996-10-07 0:00 ` Richard Riehle 1996-10-09 0:00 ` Richard A. O'Keefe 1996-10-15 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox