Syntax error in USB Audio source 6.1

[johnswenson1]

I'm using USB audio source 6.1.0rc3, when I compile the project I get a warning that says syntax errors on an asm line in main.xc.

on tile[USB_CORE]:
{
thread_speed();

/* Attach mclk count port to mclk clock-block (for feedback) */
//set_port_clock(p_for_mclk_count, clk_audio_mclk);
{
unsigned x;
asm("ldw %0, dp[clk_audio_mclk]":"=r"(x));
asm("setclk res[%0], %1"::"r"(p_for_mclk_count), "r"(x));
}

buffer(c_xud_out[EP_NUM_OUT_AUD],/* Audio Out*/
c_xud_in[EP_NUM_IN_AUD], /* Audio In */
c_xud_in[EP_NUM_IN_FB], /* Audio FB */

The warning is pointing at the first asm line, the one with the ldw.

The project compiles and I can load it on the board, but it crashes when it tries to run the code in core[1].

I'm not sure what to do about this. I kind of expected the code not to have syntax errors. The symbol clk_audio_mclk is defined in the same file so it is probably not an issue of missing includes or some such.

I haven't had time to learn XMOS assembly code yet so I don't have any clue what might be wrong with this.

Thanks,

John S.

[JasonWhiteman]

I haven't used asssembly yet either. Let me see if I can help.

1) Google: "XMOS assembly"
2) Follow first link http://www.xmos.com/assembly-programming-manual-0
Conclusion: not acceptable. Pure assembly vs. inline
3) Follow third link http://www.xmos.com/inline-assembly

asm("ldw %0, dp[clk_audio_mclk]"
:"=r"(x));

According to 1st link (general assembly reference), you are using the:

ldw d, dp[u16] form where d = register, u16 = 16-bit unsigned value. "Load word from data pool" covered in page 144 of the XS1 architecture manual. https://www.xmos.com/download/public/Th ... ?support=1

The effective instruction is:

LDWDP op1, op2

Where:

op1 = register Any of r0...r11, cp, dp, sp, lr
op2 = A 16-bit immediate in the range 0...65535.
Although there is a note in the architecture manual about prefixing - this is more of a machine-code/compiler consideration -- so we do not have to worry about this in inline asm.

...

On the face of it, I would think you need to pass "clk_audio_mclk" as an operand rather than including it into your inline assembly.

There are experts here that have more experience with inline assembly. I have none for xcore which is limiting my ability to help.

XMOS:

Is there a "real" reference for inline assembly? I've seen references to:

"ri" for immediate values, "r+" for ??, etc. which I am not seeing documentation for. Please let me know where the syntax for inline asm is documented so I can better self-serve future inline asm work.

Regards,
Jason Whiteman

[JasonWhiteman]

I stumbled on the inline assembly reference that gets me closer to bridging the gap:

http://www.ibiblio.org/gferg/ldp/GCC-In ... HOWTO.html

However, I see that the compiler is reporting that the "i" constraint (immediate) is not supported. There's another forum topic tracking a similar issue with suggestions to use full ASM (.S files) when immediate values are required.

I would be interested in learning if there is an XMOS-specific constraint or if the inline ASM implementation is limited such that this is not possible without an update to the software.

Regards,
Jason Whiteman

[segher]

I stumbled on the inline assembly reference that gets me closer to bridging the gap:

http://www.ibiblio.org/gferg/ldp/GCC-In ... HOWTO.html

That is for GCC. LLVM does not support most of what makes inline asm
useful (like proper register classes), so you end up having to pass most
things in registers always.

However, I see that the compiler is reporting that the "i" constraint (immediate) is not supported.

The C compiler supports that fine; the old XC compiler does not. That also
does not even support in/out ("+r") operands, or the "old style" more generic
back-reference ("0").

There's another forum topic tracking a similar issue with suggestions to use full ASM (.S files) when immediate values are required.

Suppose you have code like

Code: Select all

static inline void outc8(u32 c, u8 d)
{
        asm("outct res[%0],%1" : : "r"(c), "ri"(d));
}

(I do).

This code is wrong. If you ever try e.g. "outc8(c, 12);" things will
blow up: 12 is fine for "i", but the instruction does not actually allow
12. Making the "ri" constraint "r" fixes things, but now "outc8(c, 1);"
does not generate OUTCTI insns anymore. Finally, having separate
functions for immediate and register values a) prevents the compiler
from choosing what is best; b) is ugly; and c) requires whoever uses
the functions to know not to call the integer version with numbers > 11.

There are similar issues for integers 0..65535, and for r11.

[johnswenson1]

Hi Guys, thanks for the response. So it looks like that asm code should be all right. The only reason I can think of that it could be complaining about is either the clock object is not 16 bits or the "x" variable is not 16 bits.

The clock is defined earlier in the same file as:

on tile[AUDIO_IO_CORE] : clock clk_audio_mclk = XS1_CLKBLK_2;

So is a clock object a 16 bit entity?

The x variable is declared as unsigned, so I'm going to assume that the XC compiler interprets unsigned as an unsigned 16 bit object. Since the second asm line does not give an error and it uses the same variable it looks like that is not the problem. So that seems to leave the clock object as the problem.

I suppose I could go look at the .S file this xc produces and see what that clock declaration does.

Thanks,

John S.

[segher]

So it looks like that asm code should be all right.

It looks fine to me.

The only reason I can think of that it could be complaining about is either the clock object is not 16 bits or the "x" variable is not 16 bits.

The clock is defined earlier in the same file as:

on tile[AUDIO_IO_CORE] : clock clk_audio_mclk = XS1_CLKBLK_2;

So is a clock object a 16 bit entity?

This defines a variable in memory. It is 32 bits, as any resource id is.
Any clock id will fit in 16 bits, but that doesn't matter here.

The asm loads that value (the clock id) with LDWDP, which needs the
thing loaded to be relative to the DP register. It has to be at an offset
of at most 4*65535, but you do not have that much memory anyway.

The x variable is declared as unsigned, so I'm going to assume that the XC compiler interprets unsigned as an unsigned 16 bit object.

An unsigned int is 32 bits.

I suppose I could go look at the .S file this xc produces and see what that clock declaration does.

Yes. You can also show us the (exact!) error message you get (hint hint :-) ).

[JasonWhiteman]

Right, I tried several of the gnu ASM constructs and noticed that most were not supported. That said - I do not see any other resource that documents the inline assembly from a spec perspective. The XMOS documentation is more of a collection of examples than a true reference.

For the "r" vs "ri" response: I'm using the latest production version of the studio. Is this the "old" version of XC you refer to? ... and "new" version is the beta?

Regards,
Jason Whiteman

[davelacey]

Right, I tried several of the gnu ASM constructs and noticed that most were not supported. That said - I do not see any other resource that documents the inline assembly from a spec perspective. The XMOS documentation is more of a collection of examples than a true reference.

There are reference docs as well. You can find the main reference documentation for the 12.2.0 tools here:

http://www.xmos.com/download/public/xTI ... 66A%29.pdf

Section 33 describes the supported inline assembly constructs.

[johnswenson1]

Thanks guys,
I have the USB code working great. But I still get that syntax error, but it doesn't seem to matter.

It turned out the include path for the usb_audio module (which contains main.xc) was pointing to the original app directory rather than the new one I had created so it was not reading my modified .h files and was putting stuff on the wrong pins, once I got that straightened out it worked great. I even have it up and running 384.

So I now have USB running on the L2 slicekit.

John S.

[Ross]

Are you sure this isn't just a warning? A "syntax error" would indicate something that would cause the build to fail. What is the actual error message please?