|[4 earlier articles]|
|Re: New experimental back end for C/C++ compiler targeting CLI email@example.com (BartC) (2016-08-29)|
|Re: New experimental back end for C/C++ compiler targeting CLI firstname.lastname@example.org (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 email@example.com (Walter Banks) (2016-08-30)|
|Re: New experimental back end for C/C++ compiler targeting CLI firstname.lastname@example.org (BartC) (2016-08-30)|
|Re: New experimental back end for C/C++ compiler targeting CLI email@example.com (Walter Banks) (2016-08-31)|
|Re: New experimental back end for C/C++ compiler targeting CLI firstname.lastname@example.org (Martin Ward) (2016-09-06)|
|From:||Martin Ward <email@example.com>|
|Date:||Tue, 6 Sep 2016 18:09:12 +0100|
|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="firstname.lastname@example.org"|
|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
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.
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.
Dr Martin Ward STRL Principal Lecturer & Reader in Software Engineering
email@example.com 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
Return to the
Search the comp.compilers archives again.