|
The DSP56F8XX family manual rev. 1.00 indicates on page A62 that the
first argument to the BRSET instruction is a 16 bit immediate value. Further along, it states that the first argument is a MASK8 value, in which either the upper or lower half must be zero. If I assemble an instruction such as the following, the proper area of the second argument (register or memory), is not tested, but the lower half is always used (or so it would appear). BRSET #$8000,X0,Label ... Label: ... it appears that the lower half of X0 is actual tested against $80, rather than the upper half. Is this a compiler problem in the Metroworks compiler, an execution problem in the 56F807, or a documentation problem? On the other hand, maybe I am wrong, and would like someone to tell me so! On a related matter, is the specific opcode values, and instruction layout similar between the 568000E and the 56F8xx family? I have the opcode map for that processor, but have not seen that information for the 807. If I had that information, it might help understand the problem above. Thanks, Jerry L. Johnson (JJ) Principal Engineer Giddings & Lewis, LLC Controls Measurement and Sensing Fond Du Lac WI |
|
|
DSP56807 execution of BRSET instruction?
Started by ●February 1, 2002
Reply by ●February 6, 20022002-02-06
|
Hi Jerry, Our support team said... Very insightful observation....... :-) This is indeed a problem with the inline assembler for the compiler for CodeWarrior for DSP56800 (the same problem does not exist when calling the standalone assembler). However, this issue has been fixed in the upcoming 5.0 release of the tools which is scheduled for a February/March release date. I do not think it is possible to obtain the opcode map for the DSP56800 family in public form. Just for your information.........the only thing I am aware of is the instruction set listing which is available in the DSP56800 Family Manual but you are probably already aware of that. There are some similarities between the DSP56800 and DSP56800E but there are also MANY differences to take into account as well. Regards, John Whitney > The DSP56F8XX family manual rev. 1.00 indicates on page A62 that the first > argument to the BRSET instruction is a 16 bit immediate value. Further > along, it states that the first argument is a MASK8 value, in which either > the upper or lower half must be zero. If I assemble an instruction such as > the following, the proper area of the second argument (register or memory), > is not tested, but the lower half is always used (or so it would appear). > > BRSET #$8000,X0,Label > ... > Label: > ... > > it appears that the lower half of X0 is actual tested against $80, > rather than the upper half. > > Is this a compiler problem in the Metroworks compiler, an execution problem > in the 56F807, or a documentation problem? > > On the other hand, maybe I am wrong, and would like someone to tell me so! > > On a related matter, is the specific opcode values, and instruction layout > similar between the 568000E and the 56F8xx family? I have the opcode map > for that processor, but have not seen that information for the 807. If I > had that information, it might help understand the problem above. > > Thanks, > > Jerry L. Johnson (JJ) > Principal Engineer > Giddings & Lewis, LLC > Controls Measurement and Sensing > Fond Du Lac WI > -- Free Programming Courses at CodeWarrior U <http://www.codewarrioru.com> Now Including Palm OS Programming & PowerPlant Courses Metrowerks, maker of CodeWarrior - "Software Starts Here" Ron Liechty - - http://www.metrowerks.com |
Reply by ●February 7, 20022002-02-07
|
The DSP56800 family manual contains a few statements which are either misleading or incorrect. I am afraid this is one of them. The operand of BRSET and BRCLR instruction is #MASK8, where either higher or lower byte of the word is zero. The CodeWarrior compiler from Metrowerks contains two separate assembly level compilers. When you use "asm {}" statement in a C function (in-line assembly), then the code is produced by the C compiler. However when you use standalone assembly file, it is processed by standalone assembly compiler. The C compiler in Codewarrior 4.0 contains a bug, which prevents the compiler to emit correct code for BRSET and BRCLR instructions when the #MASK8 operand is greater than 256 (upper byte used). asm { brset 0x8000,x0,label brset 0x0080,x0,label label: } 0x00000000 0x8FC08002 brset #0x80,X0,*+4 ; 0x000004 0x00000002 0x8FC08000 brset #0x80,X0,*+2 ; 0x000004 As you can see, BRSET instruction with mask 0x0080 was emitted in both cases. The standalone assembly compiler does not suffer from this bug and emits correct code in both cases: brset #$8000,x0,label brset #$0080,x0,label label: 0x00000000 0x8FC08082 brset #0x8000,X0,*+4 ; 0x000004 0x00000002 0x8FC08000 brset #0x80,X0,*+2 ; 0x000004 I apologize for the bug and mistakes in our documentation. We are addressing the bug in the next release of CodeWarrior (version 5.0) which is scheduled for Feb 18th. Also the documentation is being addressed and this information will be corrected in next revision of the manual. We have the opcode map for DSP56F80x, but it is far from being a user-friendly document. If anyone is interested, please send me an e-mail. Should anyone have any problems or questions regarding DSP56800 family, please feel free to mail me or contact the helpline trough web (http://e-www.motorola.com/support/index.html). Regards, Daniel DSP Helpline Team Motorola |
|
|
Reply by ●February 11, 20022002-02-11
|
I have the metrowerks 56F8XX c++ compiler V4.0. I have been using it for more than 6 months with pure C code, without any problems. I "ported" some functional C++ code over, and although the code compiles, and appears to execute, when I step into a class constructor or any class code, the debugger goes native. I read all the included docs on the C++ compiler switches and link options, even tried changing ones that looked relevant. No joy. I am using the motorola 56F803 dev board, and a command converter, and have both flash and ram based development link command scripts, both suffer the same problem. Anyone have any ideas here? TIA |
|
|
Reply by ●February 12, 20022002-02-12
|
Yes, I have an idea... CodeWarrior for DSP56800 doesn't support C++. Leonard N. Elevich Motorola DSPD -----Original Message----- From: rootesracer [mailto:] Sent: Monday, February 11, 2002 10:28 AM To: Subject: [motoroladsp] Metrowerks C++ compiler prob? I have the metrowerks 56F8XX c++ compiler V4.0. I have been using it for more than 6 months with pure C code, without any problems. I "ported" some functional C++ code over, and although the code compiles, and appears to execute, when I step into a class constructor or any class code, the debugger goes native. I read all the included docs on the C++ compiler switches and link options, even tried changing ones that looked relevant. No joy. I am using the motorola 56F803 dev board, and a command converter, and have both flash and ram based development link command scripts, both suffer the same problem. Anyone have any ideas here? TIA _____________________________________ 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 ">http://docs.yahoo.com/info/terms/ |
Reply by ●February 12, 20022002-02-12
|
Hi,
The CodeWarrior for DSP568xx is not a C++ compiler but only a C compiler. It does not support C++ language, and there is no C++ runtime support. The link, options, flags and settings are for support of other tools and should not have any affect on DSP568xx. I think the documentation for this version may be confusing to you and if so Metrowerks apologizes for this. We have removed the confusing information from the 5.0 release. I appreciate your understanding of this matter, and hope you have an easy transition to modifying your code to be C code. Ron Ron Liechty - Ombudsman for Metrowerks Corporation > I have the metrowerks 56F8XX c++ compiler V4.0. > > I have been using it for more than 6 months with > pure C code, without any problems. > > I "ported" some functional C++ code over, and > although the code compiles, and appears to execute, > when I step into a class constructor or any class > code, the debugger goes native. > > I read all the included docs on the C++ compiler switches > and link options, even tried changing ones that looked > relevant. No joy. > > I am using the motorola 56F803 dev board, and a command converter, > and have both flash and ram based development link command scripts, > both suffer the same problem. > Anyone have any ideas here? > > TIA -- GeekWare !!! http://www.metrowerksstore.com/metrowerks/geekware.html Metrowerks, maker of CodeWarrior - "Software Starts Here" Ron Liechty - - http://www.metrowerks.com |
