* ada -> C translator @ 1997-04-03 0:00 Gabriel Monaton 1997-04-03 0:00 ` Robert A Duff [not found] ` <lvlo6iwws8.fsf@sulu.fl.ensco.com> 0 siblings, 2 replies; 30+ messages in thread From: Gabriel Monaton @ 1997-04-03 0:00 UTC (permalink / raw) Hello, Where can I find an ada -> c translator ? -- Gabriel Monaton - Sema Group/Energy Division E-mail gmn@sema-grenoble.fr Sema Group tel. (33) 04-76-41-46-00 B.P. 104 38243 Meylan CEDEX fax (33) 04-76-41-47-47 France ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-03 0:00 ada -> C translator Gabriel Monaton @ 1997-04-03 0:00 ` Robert A Duff 1997-04-03 0:00 ` Robert Dewar [not found] ` <lvlo6iwws8.fsf@sulu.fl.ensco.com> 1 sibling, 1 reply; 30+ messages in thread From: Robert A Duff @ 1997-04-03 0:00 UTC (permalink / raw) In article <33436B29.41C6@sema-grenoble.fr>, Gabriel Monaton <gmn@sema-grenoble.fr> wrote: >Where can I find an ada -> c translator ? You don't read this newsgroup much, do you? We just had a huge argument about this subject. ;-) First, what do you want: 1. Do you want it to handle the entire Ada language correctly? 2. Do you want it to produce C that is understandable to humans (e.g. C programmers)? (I.e. do you want a compiler that happens to produce C, and you'll maintain the Ada code, or do you want to throw away the Ada code, and maintain the C code?) 3. Do you want the C code to be efficient? - Bob (e-mailed and posted) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-03 0:00 ` Robert A Duff @ 1997-04-03 0:00 ` Robert Dewar 1997-04-03 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Robert Dewar @ 1997-04-03 0:00 UTC (permalink / raw) Bob Duff said <<First, what do you want: 1. Do you want it to handle the entire Ada language correctly? 2. Do you want it to produce C that is understandable to humans (e.g. C programmers)? (I.e. do you want a compiler that happens to produce C, and you'll maintain the Ada code, or do you want to throw away the Ada code, and maintain the C code?) 3. Do you want the C code to be efficient? >> To this you should add a fourth question: 4. Do you want the C code to be portable? If you get into the business of generating very low level C code, then it may well be highly target dependent (e.g. have made decisions about representation of primitive data items). ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-03 0:00 ` Robert Dewar @ 1997-04-03 0:00 ` Robert Dewar 1997-04-04 0:00 ` Fergus Henderson 1997-04-04 0:00 ` Larry Kilgallen 2 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-04-03 0:00 UTC (permalink / raw) Just to give a bit more detail on the overflow issue, and a specific example. Consider the PPC architecture with its sticky bit. The proper efficient code is to compute a whole expression, or at least a cjunk of it with no calls, and then do one test of the sticky bit. There is no way I know of to persaude a C compiler to get anywhere near to optimal code. Note: the reason that I know this particular technical problem very well is that in its current form, gcc does not know how to generate efficient overflow checks. So even though we are not generating C in GNAT, we suffer from similar limitations. Yes, we can play some tricks, like ICC did, but we can't get really efficient overflow checking, not till gcc is properly taught to handle overflow (note that the reason that gcc does not know how to generate efficient overflow checking is because C does not know about overflows!) Given that gcc started life as a C code generator, one of the dynamics of the GNAT project is that we have faced many of the same problems that one would face generating C, though not all -- critically GNU C has nested procedures, which standard C does not! A critical difference is that, unlike the situation where you are stuck generating C, we can over time teach gcc to know more about Ada specific requirements. We have taught it quite a bit -- it still needs to be taught more, notably in the areas of overflow checking and exception handling. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-03 0:00 ` Robert Dewar 1997-04-03 0:00 ` Robert Dewar @ 1997-04-04 0:00 ` Fergus Henderson 1997-04-04 0:00 ` Robert Dewar 1997-04-04 0:00 ` Richard Kenner 1997-04-04 0:00 ` Larry Kilgallen 2 siblings, 2 replies; 30+ messages in thread From: Fergus Henderson @ 1997-04-04 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Bob Duff said > ><<First, what do you want: > >1. Do you want it to handle the entire Ada language correctly? > >2. Do you want it to produce C that is understandable to humans (e.g. C >programmers)? (I.e. do you want a compiler that happens to produce C, >and you'll maintain the Ada code, or do you want to throw away the Ada >code, and maintain the C code?) > >3. Do you want the C code to be efficient? >>> > >To this you should add a fourth question: > >4. Do you want the C code to be portable? > >If you get into the business of generating very low level C code, then >it may well be highly target dependent (e.g. have made decisions about >representation of primitive data items). Yep, if you want efficiency, you may need to use machine-dependent code. However, you can get this without sacrificing portability if you keep the less efficient but portable C code as a fallback. #if THIS_SYSTEM_SUPPORTS_IT ... nonportable efficient code ... #else ... portable but not-so-efficient code ... #endif Of course, this assumes that the answer to question 2 was "no". -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-04 0:00 ` Fergus Henderson @ 1997-04-04 0:00 ` Robert Dewar 1997-04-05 0:00 ` Fergus Henderson 1997-04-04 0:00 ` Richard Kenner 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-04-04 0:00 UTC (permalink / raw) Fergus said <<Yep, if you want efficiency, you may need to use machine-dependent code. However, you can get this without sacrificing portability if you keep the less efficient but portable C code as a fallback.>> No, you missed the point. I am not talking about using non-portable constructs. The code you generate could be 100% ANSI code, but still not be portable in the sense of being movable to another target environment. For example, specific shifts might be generated whose direction depends on the endianness of the target machine. Such code could be ported, but would not behave as expected on a target of the other endianness. The point here is that if you are generating *really* low level C, it will start having the same kind of knowledge of the target architecture as a real object code generator would. Here's another example. You might decide to model a variant record as an array of chars in the C code, to avoid the difficulty of having to give a high level model. But you know the alignment requirements for such an array of bytes and you put in alignment fill bytes explicitly into your data structures. Here's another example, you are generating calls to COBOL for implementing the IS annex. You know on a specific target what COBOL passes by value and what it passes by reference, and exactly how it orders its arguments etc. You generate C code that reflects it. The C code is portable from the point of view of C semantics, but might well not be able to interface properly with the COBOL compiler on the new target. There are many many more such examples Fergus, what you say is true for general C code that tries to get better efficiency by using special non-portable constructs, but we are talking a completely different environment here when we talk about using C as a kind of low level pseudo machine language for compiler output. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-04 0:00 ` Robert Dewar @ 1997-04-05 0:00 ` Fergus Henderson 1997-04-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Fergus Henderson @ 1997-04-05 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Fergus said > ><<Yep, if you want efficiency, you may need to use machine-dependent >code. However, you can get this without sacrificing portability >if you keep the less efficient but portable C code as a fallback.>> > >No, you missed the point. I understood the point you were making. >I am not talking about using non-portable constructs. Yes you are! You talk about it in the very next sentence (emphasis mine): >The code you generate could be 100% ANSI code, but still >NOT BE PORTABLE in the sense of being movable to another target >environment. The code could be 100% "conforming" ANSI/ISO C code, but the term "conforming" applied to C code is basically useless. The term just means that there is one conforming ANSI/ISO C implementation somewhere that accepts the code, and legalistically speaking ANSI/ISO C implementations can accept Fortran code so long as they issue at least one diagnostic, so legalistically speaking Fortran code could be called 100% "conforming" ANSI C code. The code could not be 100% "strictly conforming" ANSI/ISO C code, because such code is not allowed to depend on implementation-defined or unspecified behaviour. >Here's another example. You might decide to model a variant record as >an array of chars in the C code, to avoid the difficulty of having to >give a high level model. But you know the alignment requirements for >such an array of bytes and you put in alignment fill bytes explicitly >into your data structures. In that case what you are doing is non-portable. If you want to be portable, you have to fall back to modelling variant records using a high level model, e.g. as unions. >Here's another example, you are generating calls to COBOL for implementing >the IS annex. This I admit is not something which can be done in strictly conforming ANSI/ISO C code; there's no portable way of interfacing C and COBOL. In an Ada to C compiler, the only foreign languages that you could portably interface to would be C and C++. >Fergus, what you say is true for general C code that tries to get better >efficiency by using special non-portable constructs, but we are talking >a completely different environment here when we talk about using C as >a kind of low level pseudo machine language for compiler output. I know what you're talking about. I've written a compiler (not an Ada compiler) that uses C in exactly this manner. The output is not 100% strictly conforming C (for example, we assume that there is some integral type big enough to hold a pointer), but it is close enough to be quite portable. But we don't hesitate to conditionally take advantage of non-portable features, such as shared libraries, mprotect(), struct sigcontext, GNU C global register variables, taking addresses of labels, etc., in order to improve efficiency or functionality on particular platforms. Because we do so only conditionally, this doesn't reduce portability. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-05 0:00 ` Fergus Henderson @ 1997-04-06 0:00 ` Robert Dewar 1997-04-07 0:00 ` Fergus Henderson 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-04-06 0:00 UTC (permalink / raw) Fergus quoting Robert I am not talking about using non-portable constructs. Fergus Yes you are! You talk about it in the very next sentence (emphasis mine): Fergus quoting Robert The code you generate could be 100% ANSI code, but still NOT BE PORTABLE in the sense of being movable to another target environment. >> Robert replies You are still missing the point. The C code that you generate would be portable in the sense that it would do EXACTLY the same thing on all targets, BUT remember what this code is. It is a translation of the Ada code for a particular target. The Ada code means different things on different targets for all sorts of reasons (e.g. the sizes of the appropriate types in standard, or all sorts of other impementation dependent features which for one reason or another you want to implement differently in different target enbvironments. So although there is no problem in generaing completely portable C it is NOT what you want. For example, I have an Ada program, I compile it on machine X, and I compile it on machine Y. It quite expectedly runs differently on the different machines, since the Ada program depends on some implementation dependent features (e.g. it convers an integer to a packed array using unchecked conversion, and expects the bit numbering to change as a result^H of changing endianness. Now when we compile this on machine X generating the low level C for machine X, we get the expected semantics from the portable C we are generating. Furthermore, you could move that C to machine Y, and it would do exactly the same thing it did on machine X, BUT THAT IS WRONG! Because you expect different semantics for the Ada on machine Y. The whole point here is that just because you are generating C, it does not mean that you would generate the same C on every machine. And the fact that you are generating completely standard portable ANSI-C does not change this. I don't know how to be clearer, perhaps you need to know more about the mechanics of compilers to see what I am getting at. It is kind of a critical point in this discussion. A lot of people think as you do that what you want is to take the "portable" Ada and convert it into "portable" C. This informal concept makes sense if the semantic level of the C you generate is approximately the same as the semantic level of the Ada that you start with. But we are talking here about generating very low level C, which will for instance have to reflect various requirements for the ABI in which it is generated (e.g. length of standard types, representation of types, calling sequence rules etc). So I will say it again, and maybe this time you will see that these statements are NOT incompatible. The C you will generate does not use any non-portable constructs. BUT it still will not be portable in the sense of being [usefully] movable to another target environment! The rest of what Fergus said is not relevant because of this fundamental misunderstanding. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-06 0:00 ` Robert Dewar @ 1997-04-07 0:00 ` Fergus Henderson 1997-04-07 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Fergus Henderson @ 1997-04-07 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >But we are talking here about generating very low level C, which will for >instance have to reflect various requirements for the ABI in which it >is generated (e.g. length of standard types, representation of types, >calling sequence rules etc). Why will the C generated C code have to reflect ABI requirements? Does conformance to the Ada standard require using a particular ABI? Can't an Ada implementation make up its own ABI? -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-07 0:00 ` Fergus Henderson @ 1997-04-07 0:00 ` Robert Dewar 1997-04-08 0:00 ` Fergus Henderson 1997-04-08 0:00 ` Richard A. O'Keefe 0 siblings, 2 replies; 30+ messages in thread From: Robert Dewar @ 1997-04-07 0:00 UTC (permalink / raw) Fergus said <<Why will the C generated C code have to reflect ABI requirements? Does conformance to the Ada standard require using a particular ABI? Can't an Ada implementation make up its own ABI?>> Not if it wants to properly interface to the rest of the world (pragma Import and Export are part of the langauge). Also, another point you are missing is that if you are interested in efficiency, you will tailor the C in different ways. For example, suppose you have a C compiler in which overflow checking can be done by generating code in some very particular (completely portable) manner, but on some other C compiler, this particular approach is too inefficient. Let me be very specific. suppose we have A := B + C; where all quantities are 32 bits. One approach to overflow checking is to do the arithmetic in 64 bits, and do range checking, but this requires a C compiler that supports 64 bit arithmetic, and a machine where 64-bit arithmetic is efficient. Another approach is to do the arithmetic in 32-bit unsigned, and then check sign bits. Both these generated C programs are completely portable, but you will choose which one to generate in a target dependent manner. (actually there *is* a portability question here which is the availability of 64-bit arithmetic in C -- that leads to an even sharper example, on some machines you might have to generate runtime calls to do 64-bit arithmetic). There are many, many other examples (e.g directions of shifts for packed stuff being dependent on endianness to maintain mapping with record rep specs in the expected manner). I perfectly understand why someone who does not know much about compilers would try to maintain, as Fergus does, a view that portable C is portable C and that should be that, but I am afraid that this viewpoint is plain wrong when applied at this level! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-07 0:00 ` Robert Dewar @ 1997-04-08 0:00 ` Fergus Henderson 1997-04-08 0:00 ` Robert Dewar 1997-04-08 0:00 ` Richard A. O'Keefe 1 sibling, 1 reply; 30+ messages in thread From: Fergus Henderson @ 1997-04-08 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Fergus said > ><<Why will the C generated C code have to reflect ABI requirements? >Does conformance to the Ada standard require using a particular ABI? >Can't an Ada implementation make up its own ABI?>> > >Not if it wants to properly interface to the rest of the world (pragma >Import and Export are part of the langauge). Ah, but pragma Import and Export are defined so as to allow the Ada calling convention, data sizes, etc. to be different from those used by the imported or exported code, aren't they? >Also, another point you are missing is that if you are interested in >efficiency, you will tailor the C in different ways. Of course! To elaborate on my earlier remarks: #if MACHINE_SUPPORTS_THIS ... code tailored for efficiency on machines that support this... #elif MACHINE_SUPPORTS_THAT ... code tailored for efficiency on machines that support that... #elif MACHINE_SUPPORTS_THE_OTHER ... code tailored for efficiency on machines that support the other #else ... portable but less efficient code ... #endif >Let me be very specific. > >suppose we have > > A := B + C; > >where all quantities are 32 bits. > >One approach to overflow checking is to do the arithmetic in 64 bits, and >do range checking, but this requires a C compiler that supports 64 bit >arithmetic, and a machine where 64-bit arithmetic is efficient. > >Another approach is to do the arithmetic in 32-bit unsigned, and then check >sign bits. > >Both these generated C programs are completely portable, but you will choose >which one to generate in a target dependent manner. Or alternatively, instead of choosing which code to generate at Ada-to-C translation time, you could generate C code that chooses which approach to take a preprocessing time, via conditional compilation. For example, when incrementing the Mercury stack pointer, the Mercury compiler generates code that looks like this: incr_sp(1); Here `incr_sp' is a macro defined in a header file, and conditional compilation is used to determine whether or not it checks for overflow. On some systems, the Mercury runtime uses mprotect() to get the OS to detect stack overflow. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-08 0:00 ` Fergus Henderson @ 1997-04-08 0:00 ` Robert Dewar 1997-04-08 0:00 ` William Clodius 1997-04-09 0:00 ` Fergus Henderson 0 siblings, 2 replies; 30+ messages in thread From: Robert Dewar @ 1997-04-08 0:00 UTC (permalink / raw) Fergus said <<Ah, but pragma Import and Export are defined so as to allow the Ada calling convention, data sizes, etc. to be different from those used by the imported or exported code, aren't they?>> Robert replies Of course, but, if you understand the point I was making (which I think you still miss), you will see that this is totally irrelevant. One of the requirements of an Ada compiler is that it properly duplicate calling sequences to other languages, paying attention to ABI requirements. Fergus said <<Of course! To elaborate on my earlier remarks: #if MACHINE_SUPPORTS_THIS ... code tailored for efficiency on machines that support this... #elif MACHINE_SUPPORTS_THAT ... code tailored for efficiency on machines that support that... #elif MACHINE_SUPPORTS_THE_OTHER ... code tailored for efficiency on machines that support the other #else ... portable but less efficient code ... #endif>> Robert replies Sorry, that still misses the point. Short of writing one compiler that supports all known and unknown targets, you cannot use this approach to solve the problem. Furthermore, since such choices can be quite fundamental the amount of stuff you are talking about would be huge and infeasible. For example, what shall we do with exceptions in C? There are two answers that I know of. One is to always pass an implicit exception boolean around on every call. The other is to use setjmp/longjmp. The choice between these two will radically affect the compiler, the code it generates, and the natural of the runtime library. Just trying to generate code that supported both of these possibilities would enormously complicate the compiler, and of course if I give you K more examples, then you have a 2**K way explosion of interactions that have to be considered. You are still thinking in terms of conventional C generated by humans. Sorry -- wrong level of thinking, not applicable here! Your discussion of the incr_sp approach is flawed for the same reason. It is hard enough to generate correct efficient code for a single target. To generate correct and efficient code for all possible targets using conditional compilation might be conceptually possible, but in practice is out of the question from a complexity standpoint. FAR out of the question. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-08 0:00 ` Robert Dewar @ 1997-04-08 0:00 ` William Clodius 1997-04-09 0:00 ` Fergus Henderson 1 sibling, 0 replies; 30+ messages in thread From: William Clodius @ 1997-04-08 0:00 UTC (permalink / raw) Robert Dewar wrote: > <snip> > You are still thinking in terms of conventional C generated by humans. > Sorry -- wrong level of thinking, not applicable here! > <snip> Do not assume that Fergus is thinking of C generated by humans. When you assume that you argue from an invalid position. This assumption leads to statements that imply that it is always impractical to include conditional compilation for C generated by a machine. Further, other valid statements that you make will often be ignored or misunderstood, due to the buttons such a statement will push. Fergus works all the time with C generated automatically by a compiler to C that takes into account the dependencies of a variety of systems, and is well aware that machine generated C that includes conditional compilation directives is a practical solution for many cases. The problem is not whether the code is machine or human generated, but whether for Ada in particular the complexity becomes impractical. -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-08 0:00 ` Robert Dewar 1997-04-08 0:00 ` William Clodius @ 1997-04-09 0:00 ` Fergus Henderson 1997-04-09 0:00 ` William Clodius 1997-04-09 0:00 ` Robert Dewar 1 sibling, 2 replies; 30+ messages in thread From: Fergus Henderson @ 1997-04-09 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >One of >the requirements of an Ada compiler is that it properly duplicate >calling sequences to other languages, paying attention to ABI requirements. ... >Short of writing one compiler that >supports all known and unknown targets, you cannot use this approach [the approach of compiling to C and using conditional compilation] >to solve the problem. It is true that interfacing to COBOL or Fortran cannot be done in a portable manner using C. I've already acknowledged that. However, an Ada compiler is not required to support that; such support is optional. >Furthermore, since such choices can be quite fundamental >the amount of stuff you are talking about would be huge and infeasible. There is a trade-off between efficiency, portability, and simplicity. The approach I'm talking about is certainly feasible for Mercury: we have an existence proof. Ada is more complicated than Mercury, and it may have more features that don't map nicely into C, but it's not _that_ much more complicated, so I remain unconvinced by claims that this sort of approach would be infeasible. >For example, what shall we do with exceptions in C? I implemented exceptions for Mercury without much difficulty; it took about a day. (The reason it was so easy was that the mechanism needed is similar to that needed for backtracking, which Mercury already supports, so I could reuse the same mechanism.) >There are two answers >that I know of. One is to always pass an implicit exception boolean around >on every call. The other is to use setjmp/longjmp. A third is to not use the C stack at all. Then exception handling is no problem. That's the approach taken by the Mercury implementation. In the general case, this can be fairly costly -- a factor of two or so -- but if you take advantage of GNU C extensions (using conditional compilation, of course) then the cost is very small (in some cases it can even be a win). >To generate correct and efficient code for all possible targets using >conditional compilation might be conceptually possible, but in practice >is out of the question from a complexity standpoint. FAR out of the >question. I was not suggesting that. I was talking about generating code that is correct for all targets and that is efficient for the most important targets. (In practice you may want to relax the requirement that it be "correct for all targets" and instead just aim for miminizing the difficulty of porting. For example, this may be necessary to support features that cannot be portably implemented in C, such as interfacing with COBOL.) -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-09 0:00 ` Fergus Henderson @ 1997-04-09 0:00 ` William Clodius 1997-04-09 0:00 ` Robert Dewar 1 sibling, 0 replies; 30+ messages in thread From: William Clodius @ 1997-04-09 0:00 UTC (permalink / raw) Fergus Henderson wrote: > <snip> > It is true that interfacing to COBOL or Fortran cannot be done in > a portable manner using C. I've already acknowledged that. > However, an Ada compiler is not required to support that; > such support is optional. > <snip> For Fortran you can probably do it for a wide variety of platforms by supporting F2C or NAG's F90 to C compiler. If you rely on gcc for your C compiler I suspect that you could also support g77. -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-09 0:00 ` Fergus Henderson 1997-04-09 0:00 ` William Clodius @ 1997-04-09 0:00 ` Robert Dewar 1997-04-09 0:00 ` Fergus Henderson 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-04-09 0:00 UTC (permalink / raw) Fergus said <<There is a trade-off between efficiency, portability, and simplicity. The approach I'm talking about is certainly feasible for Mercury: we have an existence proof. Ada is more complicated than Mercury, and it may have more features that don't map nicely into C, but it's not _that_ much more complicated, so I remain unconvinced by claims that this sort of approach would be infeasible. >For example, what shall we do with exceptions in C? I implemented exceptions for Mercury without much difficulty; it took about a day. (The reason it was so easy was that the mechanism needed is similar to that needed for backtracking,>> You may remain unconvinced, but it just goes to show that you have not really looked at the detailed issues of implementing Ada this way. Obviously Mercury has *much* simpler compilation semantics than Ada if it can be handled in this way -- that's entirely possible certainly. Also, it becomes clear that what you have in mind for an Ada compiler written this way is more of a small subset Ada toy than a real compiler (it is out of the question for example, for a real Ada compiler, which must implement pragma Import and pragma Export properly to consider not using an invocation stack). I think you are trying to solve a much simpler problem with Mercury (certainly sounds much simpler from all your descriptions), and you assume that this experience can be projected on to Ada, it cannot! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-09 0:00 ` Robert Dewar @ 1997-04-09 0:00 ` Fergus Henderson 1997-04-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Fergus Henderson @ 1997-04-09 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >You may remain unconvinced, but it just goes to show that you have not >really looked at the detailed issues of implementing Ada this way. Well, I do remain unconvinced. In fact, so far with each detailed issue that you have raised, the more unconvinced I have become, because the issues you have raised are either issues that the Mercury implementation deals with or issues which seem easily solvable. >Also, it becomes clear that what you have in mind for an Ada compiler >written this way is more of a small subset Ada toy than a real compiler What I had in mind was not a small subset Ada toy; I had in mind something that could be validated. (Some Ada features might require small amounts of non-portable code, but porting would still be a lot easier than porting a native-code compiler.) >(it is out of the question for example, for a real Ada compiler, which >must implement pragma Import and pragma Export properly to consider not >using an invocation stack). I don't know what you're trying to say here. I think this statement is at best vacuous, and at worst false. Certainly any implementation of a language that supports recursion is going to need an invocation stack. But an Ada implementation could use a different invocation stack than the languages that it interfaces with via pragma Import and pragma Export, and an Ada compiler that worked via compilation to C need not use the C stack as its invocation stack. Why do you suggest that this would be "out of the question"? (In case you were wondering, the Mercury implementation has a C interface which supports functionality quite similar to Ada's "pragma import" and "pragma export", and it does not use the C stack as its invocation stack.) What do you mean by a "real" Ada compiler? -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-09 0:00 ` Fergus Henderson @ 1997-04-09 0:00 ` Robert Dewar 1997-04-10 0:00 ` Fergus Henderson 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-04-09 0:00 UTC (permalink / raw) Fergus said <<What I had in mind was not a small subset Ada toy; I had in mind something that could be validated.>> Oh dear! I thought that at this stage there was *no one* left who thought that validated meant usable -- oh well. Fergus I guess you are too young to remember the early versions of Ada/Ed :-) Those who do were hopefully permanently cured of the naive assumption that validated means usable. Ada/Ed was very much a toy compiler, and yes, you certainly could create an Ada/ed equivalent in portable C, but I do not think that is what is interesting. I am giving up on trying to convince you since I don't think you have a sufficient frame of reference. If you want to prove me wrong, go ahead and translate a decent sized Ada program which uses the features of the language, including those in Annexes A-C reasonabley extensively, into the kind of C, and write the runtime that goes with it. Yes, I know that's a big job -- in fact remember that my contention is that it is an impossible job. Your work on Mercury is not even close to an example for all sorts of reasons. So, bottom line, I say that X does not exist and cannot exist, where X is a completely portable, reasonably complete, reasonabley efficient translation of Ada into C, and you say it can exist. Fine, since we are talking about existence, I see the only final proof being actual existence! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-09 0:00 ` Robert Dewar @ 1997-04-10 0:00 ` Fergus Henderson 0 siblings, 0 replies; 30+ messages in thread From: Fergus Henderson @ 1997-04-10 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Fergus said > ><<What I had in mind was not a small subset Ada toy; I had in mind >something that could be validated.>> > >Oh dear! I thought that at this stage there was *no one* left who thought >that validated meant usable -- oh well. I don't think validated necessarily means usable, but validatation does indicate that something is not a small subset. I had in mind something that was usable as well as validatable. >I am giving up on trying to convince you since I don't think you have a >sufficient frame of reference. If you want to prove me wrong, go ahead >and translate a decent sized Ada program which uses the features of the >language, including those in Annexes A-C reasonabley extensively, into >the kind of C, and write the runtime that goes with it. Does using someone else's Ada -> JVM and JVM -> C compilers count? Do consider the AdaMagic (or is it AppletMagic?) Ada to JVM compiler to be a toy? Do you consider it to be usable? When I originally wrote if you want efficiency, you may need to use machine-dependent code. However, you can get this without sacrificing portability if you keep the less efficient but portable C code as a fallback. I did not expect this to be a controversial statement. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-07 0:00 ` Robert Dewar 1997-04-08 0:00 ` Fergus Henderson @ 1997-04-08 0:00 ` Richard A. O'Keefe 1997-04-08 0:00 ` William Clodius 1997-04-08 0:00 ` Robert Dewar 1 sibling, 2 replies; 30+ messages in thread From: Richard A. O'Keefe @ 1997-04-08 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: >I perfectly understand why someone who does not know much about compilers >would try to maintain, as Fergus does, a view that portable C is portable >C and that should be that, but I am afraid that this viewpoint is plain >wrong when applied at this level! As Fergus has pointed out, only a bit more modestly, he actually knows quite a lot about compilers, and is currently _working_ on a delivered compiler for a rather interesting language, which compiler generates C. The Mercury group want the best performance they can get out of the code they generate, which means they are interested in code that adapts to the target appropriately. The possible point of difference here is that Mercury programmers expect the *same* semantics for their programs whenever possible; if I compile a Mercury program on UNIX machine X and get one set of results, I expect the _same_ results on UNIX machine Y. Nor has Fergus said that "portable C is portable C and that is that". His claim, as I understood it, was that one can translate a source program that is intended to be portable to C that can adapt to particular targets but is usable on many. Talking about interfacing to COBOL misses _his_ point, because in that case the source program isn't _intended_ to be portable (the porting target might not _have_ a COBOL compiler). -- Will maintain COBOL for money. Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-08 0:00 ` Richard A. O'Keefe @ 1997-04-08 0:00 ` William Clodius 1997-04-09 0:00 ` Fergus Henderson 1997-04-08 0:00 ` Robert Dewar 1 sibling, 1 reply; 30+ messages in thread From: William Clodius @ 1997-04-08 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > <snip> > Nor has Fergus said that "portable C is portable C and that is that". > His claim, as I understood it, was that one can translate a source > program that is intended to be portable to C that can adapt to particular > targets but is usable on many. Talking about interfacing to COBOL misses > _his_ point, because in that case the source program isn't _intended_ to > be portable (the porting target might not _have_ a COBOL compiler). > <snip> Both Robert Dewar and Fergus Henderson are talking past one another. Robert argues that there are significant machine dependencies in the translation of Ada, Fergus argues that any given machine dependency can be handled using conditional compilation. Both statements are valid and not in contradiction, but both are misleading. Fergus's points are perfectly valid for Mercury, however, this thread is not about compiling Mercury to C, but about compiling Ada to C. As a logic programming language Mercury is much more distant from the machine than is Ada. An Ada compiler to retain efficiency and correctness of translation has to be more sensitive than Mercury to machine (and C compiler) differences. If the amount of code that is processor independent is relatively small, then the usefullness of C as a portable language vanishes. The problem is not that conditional compilation cannot in principle be used to address these issues, which is what Robert Dewar's arguments seem to suggest, but rather that in the case of Ada what is possible in principle is impractical in practice. -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-08 0:00 ` William Clodius @ 1997-04-09 0:00 ` Fergus Henderson 0 siblings, 0 replies; 30+ messages in thread From: Fergus Henderson @ 1997-04-09 0:00 UTC (permalink / raw) William Clodius <wclodius@lanl.gov> writes: >An Ada compiler to retain efficiency and correctness of >translation has to be more sensitive than Mercury to machine (and C >compiler) differences. If the amount of code that is processor >independent is relatively small, then the usefullness of C as a portable >language vanishes. I don't think that follows. Even if the amount of machine-indendent code in the compiler and/or runtime is dwarfed by the amount of machine-dependent code, the ability to easily port to new machines is useful. It may require lots of additional work to make such ports efficient, but an inefficient port (or one that doesn't support interfacing to COBOL, or one that doesn't support shared libraries, etc.) is still a lot better than none at all. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-08 0:00 ` Richard A. O'Keefe 1997-04-08 0:00 ` William Clodius @ 1997-04-08 0:00 ` Robert Dewar 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-04-08 0:00 UTC (permalink / raw) iRichard O'Keefe said <<Nor has Fergus said that "portable C is portable C and that is that". His claim, as I understood it, was that one can translate a source program that is intended to be portable to C that can adapt to particular targets but is usable on many. Talking about interfacing to COBOL misses _his_ point, because in that case the source program isn't _intended_ to be portable (the porting target might not _have_ a COBOL compiler).>> I gave many other examples. The problems that people have in understanding the nature of target dependence make me think that people do not really understand what we are talking about. They still probably are thinking in terms of translation into reasonably high level C, but that's NOT possible. What we are talking about is generating very low level C, much of it at the level of semantics of assembly, and much of it incorporating target semantics. And if you do not think it is possible to write portable Ada programs that interface with COBOL, you completely misunderstand the intention of section B.4 of the RM. Sure it might be the case that a partiular source program does not use this feature of Ada 95, and you only need a subset of the language compiled. Well that of course changes the viewpoint. If you restrict the subset severely enough (no exceptions, pragma suppress assumed, no nested procedures, no variant records etc. etc. etc.), then you WILL be able to translate the Ada subset directly into C. But if you want to cover the whole language, even if you restrict yourself to the required part of the language, you will find situations in which you have to play low level games, and where it is hard, or probably impossible, to avoid target dependences in the generated C code. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-04 0:00 ` Fergus Henderson 1997-04-04 0:00 ` Robert Dewar @ 1997-04-04 0:00 ` Richard Kenner 1997-04-05 0:00 ` Fergus Henderson 1 sibling, 1 reply; 30+ messages in thread From: Richard Kenner @ 1997-04-04 0:00 UTC (permalink / raw) In article <5i243c$i1h@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: >>If you get into the business of generating very low level C code, then >>it may well be highly target dependent (e.g. have made decisions about >>representation of primitive data items). > >Yep, if you want efficiency, you may need to use machine-dependent >code. However, you can get this without sacrificing portability >if you keep the less efficient but portable C code as a fallback. No, you missed Robert's point. The issue isn't support of non-portable constructs, but representation of data items. Specifically, discriminated records. You will probably be forced to generate code that has specific offsets encoded into it. These offsets will depend on the sizes of primitive datatypes. It just *might* be possible to write all these in terms of type sizes at the C level and make it portable, but that's *really* hard if possible at all. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-04 0:00 ` Richard Kenner @ 1997-04-05 0:00 ` Fergus Henderson 0 siblings, 0 replies; 30+ messages in thread From: Fergus Henderson @ 1997-04-05 0:00 UTC (permalink / raw) kenner@lab.ultra.nyu.edu (Richard Kenner) writes: >The issue isn't support of non-portable constructs, but representation >of data items. Specifically, discriminated records. You will >probably be forced to generate code that has specific offsets encoded >into it. These offsets will depend on the sizes of primitive >datatypes. > >It just *might* be possible to write all these in terms of type sizes >at the C level and make it portable, but that's *really* hard if >possible at all. Well, it's certainly possible. Whether it is practical or not is another question. One possibility is to use union Word { long l; void *p; }; as essentially your only data type in the generated C code. Then you can use arrays instead of structs and you can calculate offsets portably. Of course, this is not efficient. But you can use conditional compilation... -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-03 0:00 ` Robert Dewar 1997-04-03 0:00 ` Robert Dewar 1997-04-04 0:00 ` Fergus Henderson @ 1997-04-04 0:00 ` Larry Kilgallen 1997-04-04 0:00 ` Robert Dewar 2 siblings, 1 reply; 30+ messages in thread From: Larry Kilgallen @ 1997-04-04 0:00 UTC (permalink / raw) In article <dewar.860115718@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > To this you should add a fourth question: > > 4. Do you want the C code to be portable? > > If you get into the business of generating very low level C code, then > it may well be highly target dependent (e.g. have made decisions about > representation of primitive data items). I was under the impression that ANSI C did not provide anything equivalent to Ada tasking. Therefore I thought that a translator would have to choose between portability and feature completeness. Larry Kilgallen ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-04 0:00 ` Larry Kilgallen @ 1997-04-04 0:00 ` Robert Dewar 1997-04-05 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1997-04-04 0:00 UTC (permalink / raw) <<I was under the impression that ANSI C did not provide anything equivalent to Ada tasking. Therefore I thought that a translator would have to choose between portability and feature completeness.>> Wrong level of thinking. At the generated code level, tasking translates into calls to the runtime library. Deciding to generate C does not remove the task of coding a runtime library -- presumably this would be coded in C, although it could also be coded in Ada (using the compiler to bootstrap, the GNAT compiler uses VERY little of the runtime in the compiler itself). But all tasking would be accomplished by using either the existing GNAT (or other Ada technology) runtime, or creating a new runtime specially for the purposes of this translator. Have a look at the -gnatdg output from GNAT, you will see that, although basically still Ada, it is a MUCH simplified subset of Ada. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-04 0:00 ` Robert Dewar @ 1997-04-05 0:00 ` Larry Kilgallen 1997-04-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Larry Kilgallen @ 1997-04-05 0:00 UTC (permalink / raw) In article <dewar.860170469@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > <<I was under the impression that ANSI C did not provide anything > equivalent to Ada tasking. Therefore I thought that a translator > would have to choose between portability and feature completeness.>> > > Wrong level of thinking. At the generated code level, tasking translates > into calls to the runtime library. Deciding to generate C does not remove > the task of coding a runtime library -- presumably this would be coded in > C, although it could also be coded in Ada (using the compiler to bootstrap, > the GNAT compiler uses VERY little of the runtime in the compiler itself). > But all tasking would be accomplished by using either the existing GNAT > (or other Ada technology) runtime, or creating a new runtime specially for > the purposes of this translator. In that case I would count that runtime library as part of the "translation" of the Ada program into C, and it seems unlikely to be portable for the tasking implementation. Or does the specification of ANSI C include Posix thread calls ? Larry ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: ada -> C translator 1997-04-05 0:00 ` Larry Kilgallen @ 1997-04-06 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1997-04-06 0:00 UTC (permalink / raw) Larry said <<In that case I would count that runtime library as part of the "translation" of the Ada program into C, and it seems unlikely to be portable for the tasking implementation. Or does the specification of ANSI C include Posix thread calls ?>> We were talkk We were talking about using C instead of assembler as a translation mechanism for Ada. Certainly if you want tasking, you will have to program a runtime library. That runtime library might lie on top of Posix threads, but it might well include all the threads mechanism. For example, the FSU threads package could be ported and used. So yes, the runtime library is most certainly part of the translation, but there is no conceptual problem in doing a complete implementation of the runtime library, including Ada tasking, in pure ANSI C. It would be work, yes, of course, but there is no conceptual problem, and you certainly do not need posix threads to be supplied in the environment to get Ada tasking working! b ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <lvlo6iwws8.fsf@sulu.fl.ensco.com>]
* Re: ada -> C translator [not found] ` <lvlo6iwws8.fsf@sulu.fl.ensco.com> @ 1997-04-17 0:00 ` Lance Kibblewhite 0 siblings, 0 replies; 30+ messages in thread From: Lance Kibblewhite @ 1997-04-17 0:00 UTC (permalink / raw) Erik Magnuson <erik@fl.ensco.com> wrote: >Gabriel Monaton <gmn@sema-grenoble.fr> writes: > >> Where can I find an ada -> c translator ? > >Here is my attempt to provide a answer for this FAQ. Unless someone objects, >I propose to trot this out each time I see this question. Hopefully, this >will enable use to discuss more important things like the proper >capitalization of keywords and identifiers ;-) > > >Short Answer: > [good answer clipped] >Medium Answer: [better answer clipped] >Long Answer: [best answer clipped] >In summary: >* It's technically possible >* It's even been done (for Ada 83 and a few specific targets) >* It's difficult (and a lot of effort) to do correctly even for a single target >* No one has even tried to do it for the "general case" (e.g. portable C) >* It's not an interesting enough solution for paying customers for there to > be an active market. So then, why do others insist on calling 'C' the universal assembler? (Yes, that was rhetorical). -- Lance. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~1997-04-17 0:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-04-03 0:00 ada -> C translator Gabriel Monaton 1997-04-03 0:00 ` Robert A Duff 1997-04-03 0:00 ` Robert Dewar 1997-04-03 0:00 ` Robert Dewar 1997-04-04 0:00 ` Fergus Henderson 1997-04-04 0:00 ` Robert Dewar 1997-04-05 0:00 ` Fergus Henderson 1997-04-06 0:00 ` Robert Dewar 1997-04-07 0:00 ` Fergus Henderson 1997-04-07 0:00 ` Robert Dewar 1997-04-08 0:00 ` Fergus Henderson 1997-04-08 0:00 ` Robert Dewar 1997-04-08 0:00 ` William Clodius 1997-04-09 0:00 ` Fergus Henderson 1997-04-09 0:00 ` William Clodius 1997-04-09 0:00 ` Robert Dewar 1997-04-09 0:00 ` Fergus Henderson 1997-04-09 0:00 ` Robert Dewar 1997-04-10 0:00 ` Fergus Henderson 1997-04-08 0:00 ` Richard A. O'Keefe 1997-04-08 0:00 ` William Clodius 1997-04-09 0:00 ` Fergus Henderson 1997-04-08 0:00 ` Robert Dewar 1997-04-04 0:00 ` Richard Kenner 1997-04-05 0:00 ` Fergus Henderson 1997-04-04 0:00 ` Larry Kilgallen 1997-04-04 0:00 ` Robert Dewar 1997-04-05 0:00 ` Larry Kilgallen 1997-04-06 0:00 ` Robert Dewar [not found] ` <lvlo6iwws8.fsf@sulu.fl.ensco.com> 1997-04-17 0:00 ` Lance Kibblewhite
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox