I am running into a weird problem. The result of a ubtraction is supposed to be positive, but I got
negative value. It looks to me that the Compiler might havegenerated wrong assembly code, or the
assembler might have generated wrong Opcode.
Need ColdFire experts to teach us how the following Opcode works.
0x91AEFFE0 ub.l d0,-32(a6)
Opcode is: 0x91AEFFE0
Assembly is: sub.l d0,-32(a6)
Is it doing
-32(a6) = -32(a6) - d0
OR,
-32(a6) = d0 - ( -32(a6) )
OR, it is doing something else ?
Regards,
JoeDoes this happen for all subtractions of the form:
a = b-a;
or only for
*(a) = b - *(a);
or only for the condition where b is a constant?
or?
Thanks.
Look at CFPRM.pdf in {install}\Freescale_Documentation, page 151 (I'm using CW7.1.1).
The Opmode is 110, therefore
<ea>x - Dy --> <ea>x
in your case:
(-32<a6>) -D0 --> (-32<a6>)
HTH,
Johan
Here is the C code, and the assembly code generated by CodeWarrior compiler.
T3_new = ATP_Timer_Get_10ms() - T3_new;
0x00009C98 0x4EB900009F88 jsr 0x00009f88
0x00009C9E 0x91AEFFE0 sub.l d0,-32(a6)
Hello
If you think the compiler is generating invalid code, I would recommend you to submit a service request for that.
Click here to submit a service request.
Make sure to attach a reproducible project and installed product information to the service request.
To generate the required information:
- Start CodeWarrior
- Open the project
- Select "Help" -> "Pack and Go" and follow instructions on the screen.
Attach the generated .zip file to the SR.
CrasyCat
Did anyone follow-up on this one and generate a service request? I seem to have come across a similar problem...
Any feedback is welcome.
Thx,
Johan
Yes, the technical support guys have confirmed that the C Compiler generated wrong code.
This is indeed a compiler bug.
Regards,
Joe
OK, thanks. Any reference number or even a version where the issue is or will be fixed?
Regards,
Johan
OK, this turns out to be more serious: The command-line compiler seems to produce this error even when optimization is turned off.
A small example program to reproduce this:
void testfn(unsigned long * fn_param) { *(fn_param) = 247 - *(fn_param); } /* Command line: mwccmcf.exe -c -g -opt none,dump -dis -o testpeep.dis testpeep.c */
This produces the following code:
; 3: *(fn_param) = 247 - *(fn_param); ; 0x00000008 0x203C000000F7 move.l #247,d0 ; '....' 0x0000000E 0x9190 sub.l d0,(a0)
I tried some other options, but the result is always the same.
I'll filea bug report for this, since I know of no workaround, and this therefore means that our command-line based make-system will produce invalid code.
If someone finds a workaround for this problem (using the command-line compiler) I'd be very interested!
Regards,
Johan
A summary:
The command-line compiler uses peephole optimization by default, even if '-opt none' is issued.
This optimization method contains the error as described above.
The documentation is in error, in that '-opt [no]peep[hole]' is not supported and results in an error. Instead, a separate option '-[no]peep[hole]' is available on the command line, as is correctly described in the command-line help using "mwccmcf -help". This option has to be indicated separately, and is not connected to the '-opt' option variants.
So, to avoid the error above when using the command-line compiler, specify '-nopeephole'.
The error is known at Freescale and registered under ID MTWX31403, to be resolved in the next few months: "... should be released before Q3".
HTH,
Johan
Dear Johan,
Your help is deeply appreciated. Unfortunately, your answer also confirm our suspicion
on the compiler/assembler problem. Due to unknown reason, the CodeWarrior for ColdFire
Development Tool generated this wrong opcode.
We have learned that there are at least two methods to avoid this compiler problem.
The first method is to change Global Optimizations to level 4.
The second method is to uncheck Peephole option under ColdFire Processor.
Thanks again.
Regards,
Joe
Can you elaborate or provide a link as to the incorrect code generated? Source and disassembly, if possible?
TIA,
Johan