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

Martin Ward <martin@gkc.org.uk>
Tue, 6 Sep 2016 18:09:12 +0100

          From comp.compilers

Related articles
[4 earlier articles]
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: Martin Ward <martin@gkc.org.uk>
Newsgroups: comp.compilers
Date: Tue, 6 Sep 2016 18:09:12 +0100
Organization: Compilers Central
References: 16-08-007 16-08-008 16-08-009 16-08-011 16-08-012 16-08-015
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="10683"; mail-complaints-to="abuse@iecc.com"
Keywords: C, code
Posted-Date: 06 Sep 2016 14:52:56 EDT

On 30/08/2016 22:48, BartC wrote:
> Then comments can either be tied to a particular instruction, or are on
> their own line and might be assumed to refer to the next block of
> instructions. (But then, they could be continuing a long comment too.)


In an early version of the FermaT Program Transformation System
(http://www.gkc.org.uk/fermat.html) we decided that the "obvious"
way to handle comments was to have an optional "comment" field in every
node of the parse tree. A comment could be attached to any statement,
expression, condition etc. and would stay attached as the code
was transformed.


The parsers used heuristics to attach a parsed comment to the nearest
likely statement: so it quickly became clear that there would be very
little need for comments attached to expressions, conditions etc.


In fact, attaching the comments to statements raised a number
of problems: every transformation had to decide what to do
with any comments attached to the code it operated on.
For example: if the statement is deleted, do we delete
the comment or leave it behind?
If the latter, which statement does it now become attached to?
If a statement is duplicated, do both copies get the comment
or just the original? Some transformations work by duplicating
code and then eliminating some or all of the copies
(for example, "Expand and Separate"). How should these deal
with comments? And so on...


After some discussion it was decided to implement comments
in the form of a "comment statement": a statement which can
appear anywhere that a normal statement appears but which
semantically has no effect (it acts the same as a SKIP statement).
This required much less work for the transformations to handle
comments correctly: most transformations just treat a comment
the same as any other statement. Some check for comments
and move them to the appropriate place, using the fact
that a comment statement can be moved anywhere
and that a comment refers to the code which follows it.


Our assembler parser (used in the commercial assembler to C and COBOL
migration system developed by Software Migrations Ltd) recognises
three classes of comments:


(1) The "Narrative Block Comment": this is the first substantial
block of comments found at the start of the module. These comments
are taken out and added to the final C or COBOL code as a block
comment at the top of the migrated module.


(2) Comment lines: a line which contains only a comment.
Typically, these are more important than comments
attached to an instruction. A sequence of comments followed
by a label will be moved to a point just after the label:
this ensures that these comments stay with the code that they
refer to, since they usually refer to the code after the label.


(3) Comments on the same line as an instruction.
Typically, these refer to details of the implementation
and are not usually relevant to the migrated code.
Some customers choose to have these comments removed
in the final migrated code. If they are required,
the comment statement will be placed just before
the code generated by the instruction.
The transformation process frequently merges simple code
into more complex statements: in this case, there will
be several comments referring to the same statement.


For more on the program transformation system see:
"Pigs from Sausages? Reengineering from Assembler to C
via FermaT Transformations" Martin Ward
Science of Computer Programming, Special Issue on Program
Transformation, Vol 52/1-3, pp 213-255, 2004.
doi:dx.doi.org/10.1016/j.scico.2004.03.007


http://www.gkc.org.uk/martin/papers/migration-t.pdf


A more recent paper on migrating assembler is
"Assembler Restructuring in FermaT" Martin Ward
13th IEEE International Working Conference on Source Code Analysis and
Manipulation, 22nd b 23rd September 2013, Eindhoven, The Netherlands.


http://www.gkc.org.uk/martin/papers/assembler-restructuring-t.pdf


--
                          Martin


Dr Martin Ward STRL Principal Lecturer & Reader in Software Engineering
martin@gkc.org.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
Mirrors: http://www.gkc.org.uk and http://www.gkc.org.uk/gkc


Post a followup to this message

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