Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Martin Ward Newsgroups: comp.compilers Subject: Re: New experimental back end for C/C++ compiler targeting CLI Date: Tue, 6 Sep 2016 18:09:12 +0100 Organization: Compilers Central Lines: 89 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-09-011@comp.compilers> References: <16-08-007@comp.compilers> <16-08-008@comp.compilers> <16-08-009@comp.compilers> <16-08-011@comp.compilers> <16-08-012@comp.compilers> <16-08-015@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="10683"; mail-complaints-to="abuse@iecc.com" Keywords: C, code Posted-Date: 06 Sep 2016 14:52:56 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:1750 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