[Coco] CC issue

[Jeff Teunissen]

What are the filenames? If they are all named comp_NN.c, that's the
decompiled source.

On Sat, Nov 9, 2019, 9:47 PM Walter Zambotti <zambotti at iinet.net.au> wrote:

> Jeff
>
> I'm using the c.comp source from the MC cross compiler which contains a
> lot of C code.  I can only assume the OS9 c.pass1 and c.pass2 are
> similar because they exhibit the same issue.
>
> Anyway debugging through c.comp it appears that preprocessor statements
> are handled separately from C statements.  Moving the logic around
> appears complicated due to internal structures that are not well
> documented.
>
> Even if I managed to find a simple fix for c.comp trying to find the
> respective fix in the c.pass1/2 is a different story as I have no source
> (unless there is source).
>
> Walter
>
> On 11/10/19 4:35 AM, Jeff Teunissen wrote:
> > Of course, I am speaking as someone looking at source, not trying to
> > grovel through a binary. build.c (comp_03.c in the decompiled source)
> > is PROBABLY where you should look (it is responsible for building the
> > compiler's expression trees), but possibly tranexp.c (AKA comp_13.c),
> > which does expression translation.
> >
> > On Sat, Nov 9, 2019 at 2:05 AM Jeff Teunissen <deek at d2dc.net> wrote:
> >> Sounds like it's actually two bugs, and both should be fairly simple.
> >>
> >> Firstly, preprocessor statements that actually make it to the compiler
> >> need to be considered new statements.
> >> Secondly, the end of a block should complete a statement.
> >>
> >> On Fri, Nov 8, 2019 at 12:52 AM Walter Zambotti <zambotti at iinet.net.au>
> wrote:
> >>> I found a small issue in both c.pass1/2 and o c_comp.
> >>>
> >>>
> >>>
> >>> In the following demonstrative code (which is not meant to be logical):
> >>>
> >>>
> >>>
> >>> main()
> >>>
> >>> {
> >>>
> >>>    int I;
> >>>
> >>>    while(i++) { i--;}
> >>>
> >>> #asm
> >>>
> >>>    clra
> >>>
> >>>    clrb
> >>>
> >>> #endasm
> >>>
> >>>    i = i + 1;
> >>>
> >>> }
> >>>
> >>>
> >>>
> >>> The asm code is incorrectly placed inside the while loop.
> >>>
> >>>
> >>>
> >>> This occurs because the compiler is looking for a semicolon after the
> loop
> >>> block.  Which of course is not required and is tolerated.
> >>>
> >>> However while it is looking for the semicolon if it comes across any
> >>> comments it outputs them immediately doing so before it has
> >>> finalised the output for the loop.
> >>>
> >>>
> >>>
> >>> This issue does effect program execution.
> >>>
> >>>
> >>>
> >>> The easy work around is to place an extraneous semicolon after the loop
> >>> block like so:
> >>>
> >>>
> >>>
> >>>    while(i++) { i--;};
> >>>
> >>> or
> >>>
> >>> while(i++) i++;;
> >>>
> >>>
> >>>
> >>> This forces the compiler to place the asm code after the loop as
> expected.
> >>>
> >>>
> >>>
> >>> This occurs for any statement block that contains exit logic such as:
> >>>
> >>>
> >>>
> >>> While, for, switch
> >>>
> >>>
> >>>
> >>> This also affects C lines added as comments to the assembly.  The C
> comment
> >>> lines appear out of context to their respective asm.
> >>>
> >>>
> >>>
> >>> This last issue does not effect program execution but makes it
> difficult to
> >>> use the assembly listing to debug your code.
> >>>
> >>>
> >>>
> >>> I have traced through c.comp extensively and the fix would not be easy.
> >>>
> >>>
> >>>
> >>> I did however manage to add a fix to c.prep so that it outputs a
> semicolon
> >>> before any asm code.  This seems to fix the
> >>> issue but would need extensive testing.
> >>>
> >>>
> >>>
> >>> Walter
> >>>
> >>>
> >>> --
> >>> Coco mailing list
> >>> Coco at maltedmedia.com
> >>> https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>