Hi,
I'm trying to use 54x DSP Library functions (cbrev, cfft1024, log_10), in pure assembly, on a 542 chip. Even though I am passing -mc to the assembler, it does not seem to be recognizing the SP as a valid MMR, or...something. The code (w/ CPL=1) is, e.g.
.asg (0), DATA stl a, *sp(DATA)but after compiling to COFF and loading through an emulator is disassembled as
STL A, IMR
overwriting my IMR (at absolute address 0). Wat. Every other attempted form of this either gives an error, overwrites the IMR, or writes directly to SP itself, and not the stack. Other instances of this (with .asg (N), NAME and references to *sp(NAME) also write to absolute address N).
There is heavy use of this form of SP-relative addressing in the DSPLIB code, and I don't think it's working properly in any of the functions. What's going on? Is this the correct way to do SP-referenced addressing? If not, can someone give me a working example?
Compiling with CCSv5 c5400 tools.
You are using the "direct addressing" addressing mode. This mode is either DP-relative or SP-relative depending on the value of the CPL bit. It looks like the assembler is encoding this instruction correctly. The behavior you are describing is consistent with the CPL bit being set to 0. Are you absolutely sure the CPL bit is 1 when that instruction is executed?
The -mc option does not affect hand-coded assembly code.
Yeah, okay, I think I found the bug. cfft1024 uses SP-relative addressing -before- setting ST1 up (which includes CPL=1), so if you don't already have CPL = 1, badness occurs.
The other annoying thing is that I actually noticed that bug early, and changed it, but the disassembler apparently doesn't pay attention to CPL, so I wandered off on that -mc tangent because the disassembled code still looked wrong. It's actually fine when I let it run, but the no matter what the value of CPL (or use of -mc), the disassembler reads op code 8000 as "STL A, IMR", never as "STL A, top-of-stack-address".
Blerg.
As to cfft1024, if it is intended to be a C-callable function, it is entitled to believe that CPL=1, as that is part of the C calling convention. If it is not intended to be a C-callable function, I can't say much about it. We'd need an expert on the library to comment on it.
As to the disassembler, yes, that is annoying. When disassembling code in the debugger, the debugger should query the status bit and disassemble accordingly. Note that if CPL changes during execution, this will not be reliable unless the PC is actually on that instruction. The C55x disassembler behaves like this. However, I don't know if it is feasible to change the C54x disassembler at this time.
As to -mc, it's not a valid C54x assembler option. How exactly are you using it?
It is intended to be called from C, but the doc (spru518d) says asm calls should be possible.
The asm tools guide (spru102f) claims that -mc is valid? I'm not using it anymore, though, I was just trying everything until I realized the disassembler was lying, and moving the ST1 setup two lines earlier fixed the problem. On the other hand, upon checking, I found that log_10 never changes CPL at all, so I guess 'possible' doesn't mean 'transparent'.
You can do anything from assembly code that you could do from C code, such as call a C-callable function. When calling a C-callable function, this means you must adhere to the C calling convention, which includes setting the status bits before calling it.
That's an error on SPRU102F; the -mc option is actually intended for C55x only.