xTimeComputer V13 Disassembly View Missing Instruction Issue

[bearcat]

Was doing some debugging. Like to look at the disassembly view.

The dissassembly view is missing an instruction. The build file shows the correct sequence and the program addresses show a missing instruction. The out instruction is not shown around line 261 in the view. See attached:

V13Dissasembly.JPG

While, the code annotation is tough to follow sometimes, I can handle that.

[davelacey]

Was doing some debugging. Like to look at the disassembly view.

The dissassembly view is missing an instruction. The build file shows the correct sequence and the program addresses show a missing instruction. The out instruction is not shown around line 261 in the view. See attached:

Are you compiling with the -fschedule option enabled? This will schedule instructions in assembly so the order in the binary will be different to the assembly file. You can get the actual instruction dump from the .xe binary using the xobjdump command line tool.

[bearcat]

Thanks Dave. I will look into the -fschedule and the implications. Not sure.

In this case, the XC code expected instructions, assembler in the build file for that routine, and disassembly shown in xTimeComposer all matched, except xTimeComposer didn't show one instruction. It was probably there by looking at the instruction addresses. But I will review, thanks.

[bearcat]

I reviewed the -fschedule directive. I am not using it.

I have found my problem (so far) with USB with my application with V13, which is why I was debugging in the prior post. This exact thread works dandy in V11. I believe all the rest of the code appears working in my total application that I have tested so far (not complete).

The XC program when compiled is missing at least two XC code lines. I didn't look in totality at this routine in assembler, but I suspect other problems.

See the attached screen shot. Code at line 132 and 134 are nowhere to be found in either the build .S file, or in the disassembler view. The application performs as if they are missing. I performed a clean and re-build twice as a check. No errors during build.

V13MissingCommands.JPG

Thoughts:
I have been suspecting issues with inline assembler for a while since V12. I have seen, but not documented, issues like this in the past by some slight issue in a inline assembler command elsewhere in a routine. Earlier this week, I saw a routine start working by removing an extra white space added to an inline assembler instruction (that routine worked in V11 with the added space). All in this routine appear correct. Not saying I have verified this yet, nor I am saying this is the issue.

[bearcat]

Well after numerous trials and other mods. Changing inline assembler instructions had no effect. But using inline assembler did. The following code works:

Code: Select all

extern int g_USBDAC1, g_USBDAC2
...
                {
                    int temp;
                    c_decouple :> temp;
                    temp = bitrev(temp);
                    asm volatile("stw %0, dp[g_USBDAC1]" :: "r" (temp));
                    //g_USBDAC1 = temp;     //V13 This doesn't work
                    c_decouple :> temp;
                    temp = bitrev(temp);
                    asm volatile("stw %0, dp[g_USBDAC2]" :: "r" (temp));
                    //g_USBDAC2 = temp;     //V13 This doesn't work
                }

I know I am using similiar in other routines. Nothing out of the ordinary here.

On the plus side, I am now streaming USB on V13 with the almost newest XUD module.

[segher]

It seems the compiler thought you're not using g_USBDAC1
and 2, so it optimised away the stores to it. Declaring these
variables volatile should then work as well.

[davelacey]

There seem to be two issues in this thread. The first is the missing instruction in the disassembly output - this seems like a tools bug and it would be appreciated if you could raise a ticket on that.

The optimization of global variables is probably just aggressive compiler optimization. In xC (or C for that matter) there is no notion of concurrent access to variables so the compiler can optimize based on what it sees in the sequential code. For example, if you compile the following at -O3:

Code: Select all

extern int g;

int f0() {
  while (1) {
    g++;
  }
}

It will optimize out all access to g since it is never used.

You cannot declare variables volatile in xC but since 13.0.0 you can use unsafe pointers. So the equivalent to above but expressing that access to g is volatile would be:

Code: Select all

int f1() {
  unsafe {
    volatile int * unsafe p_g = &g;
    while (1) {
      *p_g = *p_g + 1;
    }
  }
}

Of course, the usual caveats about race conditions etc. apply when writing code like this. Hopefully we are adding enough to xC to allow you to write safer code without this kind of tricky shared memory access (just using the communication primitives provided).

[richard]

I've tried and failed to reproduce the missing instruction in the disassembly output with simple examples - would be possible to get hold of your source?