From: | BartC <bc@freeuk.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 30 Aug 2016 22:48:49 +0100 |
Organization: | A noiseless patient Spider |
References: | 16-08-007 16-08-008 16-08-009 16-08-011 16-08-012 |
Injection-Info: | miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="23073"; mail-complaints-to="abuse@iecc.com" |
Keywords: | translator |
Posted-Date: | 30 Aug 2016 21:49:53 EDT |
On 30/08/2016 02:21, Walter Banks wrote:
> On 2016-08-29 1:52 PM, BartC wrote:
>> I've played with source-to-source translators, and never managed to
>> deal with comments properly and in the end gave up. ...
>
>
> How we handled the comments on the asm to asm translation was put the
> whole sourceline into in our case a C statement // comment with enough
> parsing information to tie it as well to the generated code. A filter
> (In our case a compiler pragma) reprocessed the listing line. It could
> have been done with a small post processing program quite easily.
I'm mainly familiar with ASM syntax that is strictly line-oriented and
with a flat code structure.
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.)
But I'm not sure what you mean by an ASM to ASM translator; from your
other remarks it sounds like this is an ASM to C translator, where the C
is then compiled to another ASM (presumably with the original comments?).
It still doesn't sound that straightforward when N commented lines in
the source end up as M commented lines in output. And surely sometimes
the comments for the source ASM are meaningless on the target?
--
Bartc
Return to the
comp.compilers page.
Search the
comp.compilers archives again.