Forums

Codewarrior 5.02 with SDK 2.4 issue.

Started by Johnson, Jerry October 8, 2002
I have recently (Last Week) received the update to my Codewarrior for DSP56800 compiler (Version 5.0 with patches 5.01, then to 5.02).  As a sanity check before updating the Motorola SDK to 2.5 I decided to compile my code and the older 2.4 SDK with the new compiler first.  In doing this I have noticed that my code size increased significantly.  The following was observed after examining the code from 4.1 and 5.02:
 
Example usage:
gpioFD = gpioOpen(BSP_DEVICE_NAME_GPIO_B,0);
 ...
gpioIoctl(gpioFD,GPIO_SETAS_INPUT,gpioPin(B,0),BSP_DEVICE_NAME_GPIO_B);
gpioIoctl(gpioFD,GPIO_SETAS_GPIO,gpioPin(B,0),BSP_DEVICE_NAME_GPIO_B);
...
 
When compiled with CW 4.1 the resulting code (for DSP56F807) is :
 
    movei    #960,X:FgpioFD
    ...
    andc    # -2,X:13c2
    andc    # -2,X:13c3
    ...
 
When compiled with CW 5.02 the resulting code is:
 
    movei    #960,X:FgpioFD
    ...
    movei    #5058,R0
    nop
    move    X:(R0),X0
    andc    # -2,X0
    move    X0,X:(R0)
    movei    #5059,R0
    nop
    move    X:(R0),X0
    andc    # -2,X0
    move    X0,X:(R0)
    ...
 
While I realize that the gpioIoctl() function includes a series of convoluted #define's, nevertheless, I would expect the compiler to generate equivalent code for this seemingly innocuous function.
I have tried different levels of optimization to no avail.
 
I recall an earlier posting that complained about this behaviour of turning what should be an atomic read/modify/write operation into a series of instructions that could be interrupted with disasterous consequences.  Since this version of the compiler does this, I would expect that SDK 2.5 would change the convoluted defines so that there might be a chance of retaining the single instruction output for the gpioIoctl() function.  However, I did a comparison of the source code between the 2 versions of the SDK, and I did not see any differences that might correct this behaviour.
 
I realize I can program around this, however, I would not have expected the need to revert to assembly language, or the periphBitClear() function directly.
 
Does the above compile into 3 instructions in SDK 2.5?
 
Am I wrong in my expectations?
 
Jerry L. Johnson (JJ)
j...@giddings.com



This issue (extremely poor object code generation in CodeWarrior version 5.0) is
also described in my message "RE: [motoroladsp] case statements - I missed 1
instruction in item 3, sorry!" on September 30, 2002 in this discussion group.
It has got to the point now that we are spending increasing amounts of our time
figuring out ways to decrease total code size, rather than just writing code.
This is a highly important issue in several of our new products, which are close
to running out of Program Flash even on the 807 chip!

We first reported this problem to Metrowerks on May 3, 2002, and have received
numerous assurances that "it is being worked on", but I guess they're too busy
fixing other bugs to do much about it.

As I'm sure you already know, CodeWarrior version 5.0 does require the use of
the SDK version 2.5. This is posted in a recent FAQ on the Motorola website.

I don't think it should be Motorola's responsibility to make significant changes
in the SDK, just to overcome deficiencies in the CodeWarrior compiler. Any good
optimizing compiler would reduce this macro to a single assembly language
instruction. I used a compiler/linker/debugger system way back in 1988 (Sierra
C for 68000) that was vastly superior to CodeWarrior in this respect. AND, the
Sierra C debugger gave you perfectly accurate results, regardless of the
optimization level that you chose (something that CodeWarrior 5.0 is incapable
of). Apparently the state-of-the-art in compiler/linker/debugger technology has
decreased significantly in the last 14+ years!

Greg Coonley of DSP OS, Inc. had a very good suggestion for creating a macro to
overcome this deficiency in the CodeWarrior compiler, in his message
"[motoroladsp] Re: CodeWarrior 4 Upgrading" on October 1, 2002. (DSP OS is the
RealTime Operating System (RTOS) we use in all our products.)

I hope this helps.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

-----Original Message-----
From: Johnson, Jerry [mailto:]
Sent: Monday, October 07, 2002 5:35 PM
To: '
Subject: [motoroladsp] Codewarrior 5.02 with SDK 2.4 issue. I have recently (Last Week) received the update to my Codewarrior for DSP56800
compiler (Version 5.0 with patches 5.01, then to 5.02). As a sanity check
before updating the Motorola SDK to 2.5 I decided to compile my code and the
older 2.4 SDK with the new compiler first. In doing this I have noticed that my
code size increased significantly. The following was observed after examining
the code from 4.1 and 5.02:

Example usage:
gpioFD = gpioOpen(BSP_DEVICE_NAME_GPIO_B,0);
...
gpioIoctl(gpioFD,GPIO_SETAS_INPUT,gpioPin(B,0),BSP_DEVICE_NAME_GPIO_B);
gpioIoctl(gpioFD,GPIO_SETAS_GPIO,gpioPin(B,0),BSP_DEVICE_NAME_GPIO_B);
...

When compiled with CW 4.1 the resulting code (for DSP56F807) is :

movei #960,X:FgpioFD
...
andc # -2,X:13c2
andc # -2,X:13c3
...

When compiled with CW 5.02 the resulting code is:

movei #960,X:FgpioFD
...
movei #5058,R0
nop
move X:(R0),X0
andc # -2,X0
move X0,X:(R0)
movei #5059,R0
nop
move X:(R0),X0
andc # -2,X0
move X0,X:(R0)
...

While I realize that the gpioIoctl() function includes a series of convoluted
#define's, nevertheless, I would expect the compiler to generate equivalent code
for this seemingly innocuous function.
I have tried different levels of optimization to no avail.

I recall an earlier posting that complained about this behaviour of turning what
should be an atomic read/modify/write operation into a series of instructions
that could be interrupted with disasterous consequences. Since this version of
the compiler does this, I would expect that SDK 2.5 would change the convoluted
defines so that there might be a chance of retaining the single instruction
output for the gpioIoctl() function. However, I did a comparison of the source
code between the 2 versions of the SDK, and I did not see any differences that
might correct this behaviour.

I realize I can program around this, however, I would not have expected the need
to revert to assembly language, or the periphBitClear() function directly.

Does the above compile into 3 instructions in SDK 2.5?

Am I wrong in my expectations?

Jerry L. Johnson (JJ)

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this
message will receive your answer. You need to do a "reply all" if you want your
answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3