[Coco] CC issue

Walter Zambotti zambotti at iinet.net.au
Sun Nov 10 06:53:45 EST 2019


Jeff. 

Yes. The file names are as you described. It appears to be disassembled code that someone has taken the time to convert to C. 

There are are lot declarations variables and functions that have not being fully named. 

I'm still debugging through the code trying to figure out why it is prematurely outputting preprocessor statements.

Walter 

Sent from my Xperia by Sony smartphone

---- Jeff Teunissen wrote ----

>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
>>
>
>-- 
>Coco mailing list
>Coco at maltedmedia.com
>https://pairlist5.pair.net/mailman/listinfo/coco


More information about the Coco mailing list