Re: New experimental back end for C/C++ compiler targeting CLI

BartC <bc@freeuk.com>
Mon, 29 Aug 2016 18:52:07 +0100

          From comp.compilers

Related articles
New experimental back end for C/C++ compiler targeting CLI alebencz@gmail.com (Alexandre) (2016-08-25)
Re: New experimental back end for C/C++ compiler targeting CLI rockbrentwood@gmail.com (2016-08-26)
Re: New experimental back end for C/C++ compiler targeting CLI DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2016-08-29)
Re: New experimental back end for C/C++ compiler targeting CLI walter@bytecraft.com (Walter Banks) (2016-08-29)
Re: New experimental back end for C/C++ compiler targeting CLI bc@freeuk.com (BartC) (2016-08-29)
Re: New experimental back end for C/C++ compiler targeting CLI walter@bytecraft.com (Walter Banks) (2016-08-29)
Re: New experimental back end for C/C++ compiler targeting CLI DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2016-08-30)
Re: New experimental back end for C/C++ compiler targeting CLI walter@bytecraft.com (Walter Banks) (2016-08-30)
Re: New experimental back end for C/C++ compiler targeting CLI bc@freeuk.com (BartC) (2016-08-30)
Re: New experimental back end for C/C++ compiler targeting CLI walter@bytecraft.com (Walter Banks) (2016-08-31)
Re: New experimental back end for C/C++ compiler targeting CLI martin@gkc.org.uk (Martin Ward) (2016-09-06)
| List of all articles for this month |
From: BartC <bc@freeuk.com>
Newsgroups: comp.compilers
Date: Mon, 29 Aug 2016 18:52:07 +0100
Organization: A noiseless patient Spider
References: 16-08-007 16-08-008 16-08-009
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

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.