topic Re: update: CodeWarrior 6.3 buggy with MCF51QE128 in ColdFire/68K Microcontrollers and Processors

CodeWarrior 6.3 buggy with MCF51QE128

WayneZ — Wed, 24 Mar 2010 07:03:45 GMT

I updated from CW 6.2.2 (4.2.0.1) to 6.3 (4.3.0.3), the latest CW for MCF51QE128. My code size went from 88K to 95K (due to libraries) and second the application no longer works. Only if I set Optimization to 0 will CW 6.3 work properly. CW 6.2.2 works fine at all optimizations levels.
What has changed so much that the new version fails? Is there some other settings I need to adjust? It will take some time to find a small example, but I have been comparing the disassembly, but the code base is large, so it is difficult to pin point an example.
Anyone have similar experience they could relate?

Thanks
Wayne

update: CodeWarrior 6.3 buggy with MCF51QE128

WayneZ — Thu, 25 Mar 2010 04:37:20 GMT

After adding this pragma to many routines I narrowed the problem to a file and peephole optimization:

#pragma optimization_level 0

Doing a binary search of that file using:

#pragma peephole off
...code...
#pragma peephole reset

I narrowed the problem to at leaset one function:

#define RADIO_FLAG_PACKET_ID (1<<1)
static uint8_t radio_last_packetID;

static void radioApi_TogglePacketID(uint8_t *packet_id)
{
    radio_last_packetID = RADIO_FLAG_PACKET_ID & (~radio_last_packetID);
    *packet_id &= ~RADIO_FLAG_PACKET_ID;
    *packet_id |= radio_last_packetID;
}

disassembly of this code with and without peephole optimization comes down to this statement:

    *packet_id &= ~RADIO_FLAG_PACKET_ID;

Here is the code disassembly differences:

; 106: static void radioApi_TogglePacketID(uint8_t *packet_id)
; 107: {
; 108:     radio_last_packetID = RADIO_FLAG_PACKET_ID & (~radio_last_packetID);
;
0x00000000                    _radioApi_TogglePacketID:
;                             radioApi_TogglePacketID:
0x00000000 0x73AD0000               mvz.b    _radio_last_packetID(a5),d1
0x00000004 0x4681                   not.l    d1
0x00000006 0xA540                   mov3q    #2,d0
0x00000008 0xC280                   and.l    d0,d1
0x0000000A 0x1B410000               move.b   d1,_radio_last_packetID(a5)
;
; 109:     *packet_id &= ~RADIO_FLAG_PACKET_ID;
;

without peephole optimization gives this:

0x0000000E 0x70FD                   moveq    #-3,d0
0x00000010 0x1210                   move.b   (a0),d1
0x00000012 0xC280                   and.l    d0,d1
0x00000014 0x1081                   move.b   d1,(a0)

with peephole optimization gives this:

0x0000000E 0xA341                   mov3q    #1,d1
0x00000010 0x0390                   bclr     d1,(a0)

Wayne

Re: update: CodeWarrior 6.3 buggy with MCF51QE128

WayneZ — Thu, 25 Mar 2010 05:29:13 GMT

Seems to me that this code with peephole optimization :

0x0000000E 0xA341 mov3q #1,d1
0x00000010 0x0390 bclr d1,(a0)

should actually look like this:

0x0000000E 0xA341 mov3q #3,d1
0x00000010 0x0390 bclr d1,(a0)

Am I wrong? I hate when I find compiler errors, because it makes all the code suspect.

Wayne

Re: update: CodeWarrior 6.3 buggy with MCF51QE128

WayneZ — Thu, 25 Mar 2010 05:38:33 GMT

Whoops, that should be:

should actually look like this:

0x0000000E 0xA341 mov3q #2,d1
0x00000010 0x0390 bclr d1,(a0)

Re: update: CodeWarrior 6.3 buggy with MCF51QE128

WayneZ — Thu, 25 Mar 2010 05:40:17 GMT

actually, I'm confused, it is late, maybe the #3 is correct. Any confirmation that this is a compler bug?

Re: update: CodeWarrior 6.3 buggy with MCF51QE128

WayneZ — Thu, 25 Mar 2010 05:44:30 GMT

Here is what CW 6.2.2 generates:

0x0000000E 0x7190                   mvz.b    (a0),d0
0x00000010 0x08800001               bclr     #1,d0
0x00000014 0x1080                   move.b   d0,(a0)

Re: update: CodeWarrior 6.3 buggy with MCF51QE128

CompilerGuru — Thu, 25 Mar 2010 07:40:28 GMT

I have the impression the compiler is right to use #1, anding with -3 means to clean the bit with the mask 2, that is the bit number 1.

The actual bug maybe further down the function in the code generated for

> *packet_id |= radio_last_packetID;

or elsewhere...

Daniel

Re: update: CodeWarrior 6.3 buggy with MCF51QE128

CompilerGuru — Thu, 29 Oct 2020 09:36:35 GMT

I reproduced the issue with CW for MCU's 10.0 beta (I don't have 6.3 installed here) .

0x0000000E  0xA341                   mov3q    #1,d1
0x00000010  0x0390                   bclr     d1,(a0)
;
;
;    7:     *packet_id |= radio_last_packetID;
;
0x00000012  0x102D0000               move.b   _radio_last_packetID(a5),d0
0x00000016  0x8280                   or.l     d0,d1
0x00000018  0x1081                   move.b   d1,(a0)

As suspected, the bug is in the code after the code shown before. The or.l reads the register which is not maintained by the peephole optimization.

I did report the issue as MTWX40806

Daniel

Re: update: CodeWarrior 6.3 buggy with MCF51QE128

WayneZ — Thu, 25 Mar 2010 09:58:58 GMT

Yes, I traced the two versions of the code, I assumed since the following statement disassembly was the same in both cases, that the other statement was incorrect, but after tracing both, I see what you say, that the following statement was not updated to match the peephole optimization of the previous statement.

I thought CW 6.3 was the latest release of CW for the QE128 ColdFire V1? The actual compiler version reported by __CWCC__ IS 4303 and the previous CW6.2.2 reports 4201.

Thanks for confirming.

Wayne