Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1733
| From | BartC <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: New experimental back end for C/C++ compiler targeting CLI |
| Date | 2016-08-29 18:52 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <16-08-011@comp.compilers> (permalink) |
| References | <16-08-007@comp.compilers> <16-08-008@comp.compilers> <16-08-009@comp.compilers> |
On 29/08/2016 09:28, Hans-Peter Diettrich wrote: > rockbrentwood@gmail.com schrieb: > >> A really good source-to-source compiler should also be making proper >> adjustments to the comments. That may even entail a degree of natural >> language >> processing! Except for the "may" part. > > Such problems occur only on source-to-source translation, where the > output should be human readable. A compilation into instructions of a > physical or virtual machine does not necessarily include comments, and > decompilation of executable code doesn't have to deal with comments at all. I've played with source-to-source translators, and never managed to deal with comments properly and in the end gave up. Take, for example, a C-like language with //-comments to end of line. Such a language is free-format so it could be written as one token per line, with a comment on each line plus comments on their own lines. Now you can have a series of tokens and comments. There may be several comments between two tokens. The comment may refer to what's gone before, or to what follows. And while it may be adjacent to a particular token, it it may be talking about a block of code consisting of hundreds of tokens. Even if translating to normalised code in the same language, it can be challenging knowing where the comments are going to go. And if to a different language where one set of tokens in the source is represented by different set of tokens in the output, which can be smaller or bigger, how to decide where each comment is to go? > The same for preprocessor statements - > can/should they be translated into equivalent high-level contstructs of > the target language, or do they have to be expanded before a translation? The preprocessor was one reason I never got round to a source-to-source translator with C code as input. I intended this to be a *one-time* translation from C, to my own syntax; once done, I could discard the C. However, what to do about conditional code in the source? If it selects between code-sequence A and B according to some condition, I can only translate A or B, not both. The condition might be some external macro (from a third party header that in future could be different, or it could be a compile-time option. And in general there will be nested conditional code). With a normal compiler, it doesn't matter: each time it runs, it will generate either A or B as required. With a one-time translator, I have to choose one! (Or map it to conditional code in my language. But I wanted to get away from C and its preprocessor.) -- Bartc
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
New experimental back end for C/C++ compiler targeting CLI Alexandre <alebencz@gmail.com> - 2016-08-25 10:40 -0300
Re: New experimental back end for C/C++ compiler targeting CLI rockbrentwood@gmail.com - 2016-08-26 12:54 -0700
Re: New experimental back end for C/C++ compiler targeting CLI Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-08-29 10:28 +0200
Re: New experimental back end for C/C++ compiler targeting CLI BartC <bc@freeuk.com> - 2016-08-29 18:52 +0100
Re: New experimental back end for C/C++ compiler targeting CLI Walter Banks <walter@bytecraft.com> - 2016-08-29 21:21 -0400
Re: New experimental back end for C/C++ compiler targeting CLI Walter Banks <walter@bytecraft.com> - 2016-08-30 13:44 -0400
Re: New experimental back end for C/C++ compiler targeting CLI BartC <bc@freeuk.com> - 2016-08-30 22:48 +0100
Re: New experimental back end for C/C++ compiler targeting CLI Walter Banks <walter@bytecraft.com> - 2016-08-31 13:24 -0400
Re: New experimental back end for C/C++ compiler targeting CLI Martin Ward <martin@gkc.org.uk> - 2016-09-06 18:09 +0100
Re: New experimental back end for C/C++ compiler targeting CLI Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2016-08-30 13:13 +0200
Re: New experimental back end for C/C++ compiler targeting CLI Walter Banks <walter@bytecraft.com> - 2016-08-29 13:15 -0400
csiph-web