Sign in

Not a member? | Forgot your Password?

Search motoroladsp

Search tips

Find us on Facebook!





Subscribe to motoroladsp

Search tips

Free PDF Downloads

A Quadrature Signals Tutorial: Complex, But Not Complicated

Understanding the 'Phasing Method' of Single Sideband Demodulation

Complex Digital Signal Processing in Telecommunications

Introduction to Sound Processing

C++ Tutorial

Introduction of C Programming for DSP Applications

Fixed-Point Arithmetic: An Introduction

Cascaded Integrator-Comb (CIC) Filter Introduction

Discussion Groups

FFT Spectral Analysis Software

See Also

Embedded SystemsFPGA

Discussion Groups | Freescale DSPs | DSP56807 execution of BRSET instruction?

Technical discussions about Freescale (Motorola) DSPs (including the DSP56000, DSP56300, DSP56600, 56800 DSPs).

  

Post a new Thread



Is this thread worth a thumbs up?

0

DSP56807 execution of BRSET instruction? - Johnson, Jerry - Feb 1 22:59:00 2002

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







Re: DSP56807 execution of BRSET instruction? - MW Ron - Feb 6 22:03:00 2002

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






Re: DSP56807 execution of BRSET instruction? - Daniel Malik - Feb 7 13:30:00 2002

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







Metrowerks C++ compiler prob? - rootesracer - Feb 11 17:28:00 2002

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







RE: Metrowerks C++ compiler prob? - Motorola DSPD News - Feb 12 15:42:00 2002

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
_____________________________________
/groups.php3






Re: Metrowerks C++ compiler prob? - MW Ron - Feb 12 16:21:00 2002

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