|
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 |