If you check the 56300 Family manual in section 3.2.1(page 52), you will find
your answer...
http://www.freescale.com/files/dsp/doc/ref_manual/DSP56300FM.pdf?fsrch=1
On the 56K, operands are _left_ justified. There is an implied decimal point.
This means instead of #$1 representing 2^0 or 1 as you would expect, it
actually represents 2^-1 or 1/2.
Now if you multiply 2^-1 by 2^-1, you end up with 2^-2 or 1/4. This has a 1 in
the 2nd bit position over from the left. Thus if you are just looking at the
encoding, this would read back(assuming the tool you use just pulls the number
back as the same as the assembler interprets it and doesn't attempt a
floating point representation) as 2.
It has been many years since I've actually programmed the 56k series(did a
bit on the 56k, little or none on the 563xx). I got bit by this fairly early
on(that and IIR functions "blowing up" due to the wrong sign in the equations,
another story).
It is also possible to have results pre- bit shifted from various operands.
Best Regards,
Glen Farrell
Posted by: "m...@yahoo.fr" m...@yahoo.fr max2mil5
Thu Jan 11, 2007 5:24 am (PST)
Hi :-)
I am starting to learn DSP56300 (Motorola) and i meet a problem with the "mac"
instruction
i explain my problem:
Xo register contain for example $1
Yo register contain for example $1
The A register is cleared before the mac instruction
when the mac instruction excute, the result in A register is $2 !!!! why not $1
????
here is aportion of the code:
clr a
move #$1,x0
move #$1,y0
mac x0,y0,a
i use suite56 for simulation.
ty to send me an explaination of this problem and sorry for my bad english :-)
