Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #1733

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

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 <bc@freeuk.com>
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> (permalink)
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

Show key headers only | View raw


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


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