Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border1.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: BartC Newsgroups: comp.compilers Subject: Re: New experimental back end for C/C++ compiler targeting CLI Date: Mon, 29 Aug 2016 18:52:07 +0100 Organization: A noiseless patient Spider Lines: 57 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-08-011@comp.compilers> References: <16-08-007@comp.compilers> <16-08-008@comp.compilers> <16-08-009@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="25357"; mail-complaints-to="abuse@iecc.com" Keywords: translator Posted-Date: 29 Aug 2016 15:00:38 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1733 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