CMPY in c64+ (complex number representation convention)

Hi,

Till now I have been following the real first
imaginary second convention for representing complex
numbers -- Cause the dsplib functions for complex fft
stated so & much of Ti literature.

a[0], a[1] -- where a[0] is real part & a[1] imaginary
part

But now I came across CMPY instruction in c64+, so
though of replacing it with DOTP2 & DOTNP2 pair. But,
its explanation seem to direct to imaginary first &
real second kind of ordering both for the inputs & for
the product.

Can someone give me the reason behind this & also let
me know the right convention for c64 architecture
[Tis literature seem to be confusing the reader,
clearly some places follow one convention & some the
other different pages of the same document do have
this problem].
Thanks,
-Mike.

____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index Start a New Thread

Jeff,

I am confused. Can you please let me know the correct
ordering for R/I pair in memory for TI architectures?

Is it 1 or 2?

1.
struct complex
{
short Real;
Short Imag;
};

2.
struct complex
{
short Imag;
Short Real;
};

Thanks a lot,
-Mike.
--- Jeff Brower wrote:

> Michael-
>
> > Till now I have been following the real first
> > imaginary second convention for representing
> complex
> > numbers -- Cause the dsplib functions for complex
> fft
> > stated so & much of Ti literature.
> >
> > a[0], a[1] -- where a[0] is real part & a[1]
> imaginary
> > part
> >
> > But now I came across CMPY instruction in c64+, so
> > though of replacing it with DOTP2 & DOTNP2 pair.
> But,
> > its explanation seem to direct to imaginary first
> &
> > real second kind of ordering both for the inputs &
> for
> > the product.
> >
> > Can someone give me the reason behind this & also
> let
> > me know the right convention for c64 architecture
> > [Tis literature seem to be confusing the reader,
> > clearly some places follow one convention & some
> the
> > other different pages of the same document do
> have
> > this problem].
>
> It would be very unlikely after all these years and
> established conventions for DSP for TI programmers
> to try and
> switch around R/I pair ordering in memory. Which TI
> document is it?
>
> One thing you might do is write directly to the TI
> authors of the document and ask "why". If they
> really did that,
> then they would need to have a very good reason.
>
> -Jeff

____________________________________________________________________________________
Don't get soaked. Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather Start a New Thread

Michael-

> Thanks for the info., and thats how I have been
> coding (Sorry, I am very new to Tis world), based on
> complex structure ordering (1).
>
> CMPY (.unit) src1, src2, dst_o:dst_e instruction in
> c64+ architecture does the following:
>
> SAT((lsb16(src1) msb16(src2)) + (msb16(src1) br /> > lsb16(src2))) dst_e (Imag part)
> (msb 16(src1) msb16(src2)) − (lsb16(src1) br /> > lsb16(src2)) dst_o (Real part)
>
> This confirms that both input & output are ordered
> like structure (2).

Are you sure? "o" sounds like odd to me, and "e" even. What are the actual physical
addresses of struct1.Real and struct1.Imag if you look them up in the .map file?

-Jeff

> --- Jeff Brower wrote:
>
> > Michael-
> >
> > > I am confused. Can you please let me know the
> > correct
> > > ordering for R/I pair in memory for TI
> > architectures?
> > >
> > > Is it 1 or 2?
> > >
> > > 1.
> > > struct complex
> > > {
> > > short Real;
> > > Short Imag;
> > > };
> > >
> > > 2.
> > > struct complex
> > > {
> > > short Imag;
> > > Short Real;
> > > };
> >
> > First one.
> >
> > -Jeff
> >
> > PS. Please reply to the group. My job does not
> > permit me to discuss outside the
> > group.
> >
> > -Jeff
> >
> > > --- Jeff Brower wrote:
> > >
> > > > Michael-
> > > >
> > > > > Till now I have been following the real first
> > > > > imaginary second convention for representing
> > > > complex
> > > > > numbers -- Cause the dsplib functions for
> > complex
> > > > fft
> > > > > stated so & much of Ti literature.
> > > > >
> > > > > a[0], a[1] -- where a[0] is real part & a[1]
> > > > imaginary
> > > > > part
> > > > >
> > > > > But now I came across CMPY instruction in
> > c64+, so
> > > > > though of replacing it with DOTP2 & DOTNP2
> > pair.
> > > > But,
> > > > > its explanation seem to direct to imaginary
> > first
> > > > &
> > > > > real second kind of ordering both for the
> > inputs &
> > > > for
> > > > > the product.
> > > > >
> > > > > Can someone give me the reason behind this &
> > also
> > > > let
> > > > > me know the right convention for c64
> > architecture
> > > > > [Tis literature seem to be confusing the
> > reader,
> > > > > clearly some places follow one convention &
> > some
> > > > the
> > > > > other C different pages of the same document
> > do
> > > > have
> > > > > this problem].
> > > >
> > > > It would be very unlikely after all these years
> > and
> > > > established conventions for DSP for TI
> > programmers
> > > > to try and
> > > > switch around R/I pair ordering in memory.
> > Which TI
> > > > document is it?
> > > >
> > > > One thing you might do is write directly to the
> > TI
> > > > authors of the document and ask "why". If they
> > > > really did that,
> > > > then they would need to have a very good reason.
> > > >
> > > > -Jeff Start a New Thread

Michael-

> Input side:
> ==========>
> Structure (1) when accessed using 32bit or 64bit load
> (little endian), Real will be lsb16 & Imaginary will
> be msb16
>
> So, complex multiplication will yield the following
> Real part:
>
> (lsb16(src1) lsb16(src2)) − (msb16(src1) br />
> msb16(src2))
>
> Structure (2) when accessed using 32bit or 64bit load
> (little endian), Real will be msb16 & Imaginary will
> be lsb16
>
> So, complex multiplication will yield the following
> Real part:
>
> (msb16(src1) msb16(src2)) − (lsb16(src1) br />
> lsb16(src2))
>
> Now Output side:
> ==============> The output is 32bits, you are right about o (odd) & e
> (even). Even is even number register & Odd is odd
> number register. When it is written into memory (64bit
> access), even gets written 1st (Imaginary as per the
> CMPY instruction) & then odd gets written next (Real).
> So, it does Imaginary followed by Real ordering.
>
> Both Input & Output are in Imaginary followed by Real
> ordering.
>
> Please let me know if you find anything wrong here.

Well, your first comment: "real is lsb16" -- that means real is even and pair
ordering is real first, imag second. Again, this is easy to resolve by just looking
at physical mem addresses. If the real value ends up on even physical address, then
it's first in the pair.

-Jeff

> --- Jeff Brower wrote:
>
> > Michael-
> >
> > > Thanks for the info., and thats how I have been
> > > coding (Sorry, I am very new to Tis world),
> > based on
> > > complex structure ordering (1).
> > >
> > > CMPY (.unit) src1, src2, dst_o:dst_e instruction
> > in
> > > c64+ architecture does the following:
> > >
> > > SAT((lsb16(src1) msb16(src2)) + (msb16(src1) br /> > > > lsb16(src2))) dst_e (Imag part)
> > > (msb 16(src1) msb16(src2)) − (lsb16(src1)
> > br /> > > > lsb16(src2)) dst_o (Real part)
> > >
> > > This confirms that both input & output are ordered
> > > like structure (2).
> >
> > Are you sure? "o" sounds like odd to me, and "e"
> > even. What are the actual physical
> > addresses of struct1.Real and struct1.Imag if you
> > look them up in the .map file?
> >
> > -Jeff
> >
> > > --- Jeff Brower wrote:
> > >
> > > > Michael-
> > > >
> > > > > I am confused. Can you please let me know the
> > > > correct
> > > > > ordering for R/I pair in memory for TI
> > > > architectures?
> > > > >
> > > > > Is it 1 or 2?
> > > > >
> > > > > 1.
> > > > > struct complex
> > > > > {
> > > > > short Real;
> > > > > Short Imag;
> > > > > };
> > > > >
> > > > > 2.
> > > > > struct complex
> > > > > {
> > > > > short Imag;
> > > > > Short Real;
> > > > > };
> > > >
> > > > First one.
> > > >
> > > > -Jeff
> > > >
> > > > PS. Please reply to the group. My job does not
> > > > permit me to discuss outside the
> > > > group.
> > > >
> > > > -Jeff
> > > >
> > > > > --- Jeff Brower
> > wrote:
> > > > >
> > > > > > Michael-
> > > > > >
> > > > > > > Till now I have been following the real
> > first
> > > > > > > imaginary second convention for
> > representing
> > > > > > complex
> > > > > > > numbers -- Cause the dsplib functions for
> > > > complex
> > > > > > fft
> > > > > > > stated so & much of Ti literature.
> > > > > > >
> > > > > > > a[0], a[1] -- where a[0] is real part &
> > a[1]
> > > > > > imaginary
> > > > > > > part
> > > > > > >
> > > > > > > But now I came across CMPY instruction in
> > > > c64+, so
> > > > > > > though of replacing it with DOTP2 & DOTNP2
> > > > pair.
> > > > > > But,
> > > > > > > its explanation seem to direct to
> > imaginary
> > > > first
> > > > > > &
> > > > > > > real second kind of ordering both for the
> > > > inputs &
> > > > > > for
> > > > > > > the product.
> > > > > > >
> > > > > > > Can someone give me the reason behind this
> > &
> > > > also
> > > > > > let
> > > > > > > me know the right convention for c64
> > > > architecture
> > > > > > > [Tis literature seem to be confusing the
> > > > reader,
> > > > > > > clearly some places follow one convention
> > &
> > > > some
> > > > > > the
> > > > > > > other C different pages of the same
> > document
> > > > do
> > > > > > have
> > > > > > > this problem].
> > > > > >
> > > > > > It would be very unlikely after all these
> > years
> > > > and
> > > > > > established conventions for DSP for TI
> > > > programmers
> > > > > > to try and
> > > > > > switch around R/I pair ordering in memory.
> > > > Which TI
> > > > > > document is it?
> > > > > >
> > > > > > One thing you might do is write directly to
> > the
> > > > TI
> > > > > > authors of the document and ask "why". If
> > they
> > > > > > really did that,
> > > > > > then they would need to have a very good
> > reason.
> > > > > >
> > > > > > -Jeff
> >
> ____________________________________________________________________________________
> Sucker-punch spam with award-winning protection.
> Try the free Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/features_spam.html Start a New Thread

Michael-

> Till now I have been following the real first
> imaginary second convention for representing complex
> numbers -- Cause the dsplib functions for complex fft
> stated so & much of Ti literature.
>
> a[0], a[1] -- where a[0] is real part & a[1] imaginary
> part
>
> But now I came across CMPY instruction in c64+, so
> though of replacing it with DOTP2 & DOTNP2 pair. But,
> its explanation seem to direct to imaginary first &
> real second kind of ordering both for the inputs & for
> the product.
>
> Can someone give me the reason behind this & also let
> me know the right convention for c64 architecture
> [Tis literature seem to be confusing the reader,
> clearly some places follow one convention & some the
> other different pages of the same document do have
> this problem].

It would be very unlikely after all these years and established conventions for DSP for TI programmers to try and
switch around R/I pair ordering in memory. Which TI document is it?

One thing you might do is write directly to the TI authors of the document and ask "why". If they really did that,
then they would need to have a very good reason.

-Jeff Start a New Thread

Jeff,

Input side:
==========
Structure (1) when accessed using 32bit or 64bit load
(little endian), Real will be lsb16 & Imaginary will
be msb16

So, complex multiplication will yield the following
Real part:

(lsb16(src1) lsb16(src2)) − (msb16(src1) br /> msb16(src2))

Structure (2) when accessed using 32bit or 64bit load
(little endian), Real will be msb16 & Imaginary will
be lsb16

So, complex multiplication will yield the following
Real part:

(msb16(src1) msb16(src2)) − (lsb16(src1) br /> lsb16(src2))

Now Output side:
==============The output is 32bits, you are right about o (odd) & e
(even). Even is even number register & Odd is odd
number register. When it is written into memory (64bit
access), even gets written 1st (Imaginary as per the
CMPY instruction) & then odd gets written next (Real).
So, it does Imaginary followed by Real ordering.

Both Input & Output are in Imaginary followed by Real
ordering.

Please let me know if you find anything wrong here.

Cheers,
-Mike.

--- Jeff Brower wrote:

> Michael-
>
> > Thanks for the info., and thats how I have been
> > coding (Sorry, I am very new to Tis world),
> based on
> > complex structure ordering (1).
> >
> > CMPY (.unit) src1, src2, dst_o:dst_e instruction
> in
> > c64+ architecture does the following:
> >
> > SAT((lsb16(src1) msb16(src2)) + (msb16(src1) br /> > > lsb16(src2))) dst_e (Imag part)
> > (msb 16(src1) msb16(src2)) − (lsb16(src1)
> br /> > > lsb16(src2)) dst_o (Real part)
> >
> > This confirms that both input & output are ordered
> > like structure (2).
>
> Are you sure? "o" sounds like odd to me, and "e"
> even. What are the actual physical
> addresses of struct1.Real and struct1.Imag if you
> look them up in the .map file?
>
> -Jeff
>
> > --- Jeff Brower wrote:
> >
> > > Michael-
> > >
> > > > I am confused. Can you please let me know the
> > > correct
> > > > ordering for R/I pair in memory for TI
> > > architectures?
> > > >
> > > > Is it 1 or 2?
> > > >
> > > > 1.
> > > > struct complex
> > > > {
> > > > short Real;
> > > > Short Imag;
> > > > };
> > > >
> > > > 2.
> > > > struct complex
> > > > {
> > > > short Imag;
> > > > Short Real;
> > > > };
> > >
> > > First one.
> > >
> > > -Jeff
> > >
> > > PS. Please reply to the group. My job does not
> > > permit me to discuss outside the
> > > group.
> > >
> > > -Jeff
> > >
> > > > --- Jeff Brower
> wrote:
> > > >
> > > > > Michael-
> > > > >
> > > > > > Till now I have been following the real
> first
> > > > > > imaginary second convention for
> representing
> > > > > complex
> > > > > > numbers -- Cause the dsplib functions for
> > > complex
> > > > > fft
> > > > > > stated so & much of Ti literature.
> > > > > >
> > > > > > a[0], a[1] -- where a[0] is real part &
> a[1]
> > > > > imaginary
> > > > > > part
> > > > > >
> > > > > > But now I came across CMPY instruction in
> > > c64+, so
> > > > > > though of replacing it with DOTP2 & DOTNP2
> > > pair.
> > > > > But,
> > > > > > its explanation seem to direct to
> imaginary
> > > first
> > > > > &
> > > > > > real second kind of ordering both for the
> > > inputs &
> > > > > for
> > > > > > the product.
> > > > > >
> > > > > > Can someone give me the reason behind this
> &
> > > also
> > > > > let
> > > > > > me know the right convention for c64
> > > architecture
> > > > > > [Tis literature seem to be confusing the
> > > reader,
> > > > > > clearly some places follow one convention
> &
> > > some
> > > > > the
> > > > > > other C different pages of the same
> document
> > > do
> > > > > have
> > > > > > this problem].
> > > > >
> > > > > It would be very unlikely after all these
> years
> > > and
> > > > > established conventions for DSP for TI
> > > programmers
> > > > > to try and
> > > > > switch around R/I pair ordering in memory.
> > > Which TI
> > > > > document is it?
> > > > >
> > > > > One thing you might do is write directly to
> the
> > > TI
> > > > > authors of the document and ask "why". If
> they
> > > > > really did that,
> > > > > then they would need to have a very good
> reason.
> > > > >
> > > > > -Jeff
>

____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html Start a New Thread

Jeff,

Thanks for the info., and thats how I have been
coding (Sorry, I am very new to Tis world), based on
complex structure ordering (1).

CMPY (.unit) src1, src2, dst_o:dst_e instruction in
c64+ architecture does the following:

SAT((lsb16(src1) msb16(src2)) + (msb16(src1) br /> lsb16(src2))) dst_e (Imag part)
(msb 16(src1) msb16(src2)) − (lsb16(src1) br /> lsb16(src2)) dst_o (Real part)

This confirms that both input & output are ordered
like structure (2).

The simulation results confirm with the document. Like
you mentioned I will write to TI to find out more on
this (I am very curious).

About last email, sorry I didnt purposefully take it
offline, I accidentally hit the wrong button on Yahoo!
& I also re-sent another copy including the forum.

Thanks a lot & have a nice day,
-Mike.

--- Jeff Brower wrote:

> Michael-
>
> > I am confused. Can you please let me know the
> correct
> > ordering for R/I pair in memory for TI
> architectures?
> >
> > Is it 1 or 2?
> >
> > 1.
> > struct complex
> > {
> > short Real;
> > Short Imag;
> > };
> >
> > 2.
> > struct complex
> > {
> > short Imag;
> > Short Real;
> > };
>
> First one.
>
> -Jeff
>
> PS. Please reply to the group. My job does not
> permit me to discuss outside the
> group.
>
> -Jeff
>
> > --- Jeff Brower wrote:
> >
> > > Michael-
> > >
> > > > Till now I have been following the real first
> > > > imaginary second convention for representing
> > > complex
> > > > numbers -- Cause the dsplib functions for
> complex
> > > fft
> > > > stated so & much of Ti literature.
> > > >
> > > > a[0], a[1] -- where a[0] is real part & a[1]
> > > imaginary
> > > > part
> > > >
> > > > But now I came across CMPY instruction in
> c64+, so
> > > > though of replacing it with DOTP2 & DOTNP2
> pair.
> > > But,
> > > > its explanation seem to direct to imaginary
> first
> > > &
> > > > real second kind of ordering both for the
> inputs &
> > > for
> > > > the product.
> > > >
> > > > Can someone give me the reason behind this &
> also
> > > let
> > > > me know the right convention for c64
> architecture
> > > > [Tis literature seem to be confusing the
> reader,
> > > > clearly some places follow one convention &
> some
> > > the
> > > > other C different pages of the same document
> do
> > > have
> > > > this problem].
> > >
> > > It would be very unlikely after all these years
> and
> > > established conventions for DSP for TI
> programmers
> > > to try and
> > > switch around R/I pair ordering in memory.
> Which TI
> > > document is it?
> > >
> > > One thing you might do is write directly to the
> TI
> > > authors of the document and ask "why". If they
> > > really did that,
> > > then they would need to have a very good reason.
> > >
> > > -Jeff
> > >
> > >
> >
> >
> ____________________________________________________________________________________
> > Be a PS3 game guru.
> > Get your game face on with the latest PS3 news and
> previews at Yahoo! Games.
> >
> http://videogames.yahoo.com/platform?platform0121
>

____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?pSTDEAL Start a New Thread

Jeff,

Just now received a reply from Ti-Support.

Yes indeed the CMPY x64+ instruction assumes a0j + a1
approach; as this is used quite extensively in Ti
fft16 libraries as per the reply (may be
internally).

Thanks a lot for spending time with me on this & have
a nice evening,
-Mike.

--- Jeff Brower wrote:

> Michael-
>
> > Input side:
> > ==========> >
> > Structure (1) when accessed using 32bit or 64bit
> load
> > (little endian), Real will be lsb16 & Imaginary
> will
> > be msb16
> >
> > So, complex multiplication will yield the
> following
> > Real part:
> >
> > (lsb16(src1) lsb16(src2)) − (msb16(src1) br /> >
> > msb16(src2))
> >
> > Structure (2) when accessed using 32bit or 64bit
> load
> > (little endian), Real will be msb16 & Imaginary
> will
> > be lsb16
> >
> > So, complex multiplication will yield the
> following
> > Real part:
> >
> > (msb16(src1) msb16(src2)) − (lsb16(src1) br /> >
> > lsb16(src2))
> >
> > Now Output side:
> > ==============> > The output is 32bits, you are right about o (odd)
> & e
> > (even). Even is even number register & Odd is odd
> > number register. When it is written into memory
> (64bit
> > access), even gets written 1st (Imaginary as per
> the
> > CMPY instruction) & then odd gets written next
> (Real).
> > So, it does Imaginary followed by Real ordering.
> >
> > Both Input & Output are in Imaginary followed by
> Real
> > ordering.
> >
> > Please let me know if you find anything wrong
> here.
>
> Well, your first comment: "real is lsb16" -- that
> means real is even and pair
> ordering is real first, imag second. Again, this is
> easy to resolve by just looking
> at physical mem addresses. If the real value ends
> up on even physical address, then
> it's first in the pair.
>
> -Jeff
>
> > --- Jeff Brower wrote:
> >
> > > Michael-
> > >
> > > > Thanks for the info., and thats how I have
> been
> > > > coding (Sorry, I am very new to Tis world),
> > > based on
> > > > complex structure ordering (1).
> > > >
> > > > CMPY (.unit) src1, src2, dst_o:dst_e
> instruction
> > > in
> > > > c64+ architecture does the following:
> > > >
> > > > SAT((lsb16(src1) msb16(src2)) +
> (msb16(src1) br /> > > > > lsb16(src2))) dst_e (Imag part)
> > > > (msb 16(src1) msb16(src2)) −
> (lsb16(src1)
> > > br /> > > > > lsb16(src2)) dst_o (Real part)
> > > >
> > > > This confirms that both input & output are
> ordered
> > > > like structure (2).
> > >
> > > Are you sure? "o" sounds like odd to me, and
> "e"
> > > even. What are the actual physical
> > > addresses of struct1.Real and struct1.Imag if
> you
> > > look them up in the .map file?
> > >
> > > -Jeff
> > >
> > > > --- Jeff Brower
> wrote:
> > > >
> > > > > Michael-
> > > > >
> > > > > > I am confused. Can you please let me know
> the
> > > > > correct
> > > > > > ordering for R/I pair in memory for TI
> > > > > architectures?
> > > > > >
> > > > > > Is it 1 or 2?
> > > > > >
> > > > > > 1.
> > > > > > struct complex
> > > > > > {
> > > > > > short Real;
> > > > > > Short Imag;
> > > > > > };
> > > > > >
> > > > > > 2.
> > > > > > struct complex
> > > > > > {
> > > > > > short Imag;
> > > > > > Short Real;
> > > > > > };
> > > > >
> > > > > First one.
> > > > >
> > > > > -Jeff
> > > > >
> > > > > PS. Please reply to the group. My job does
> not
> > > > > permit me to discuss outside the
> > > > > group.
> > > > >
> > > > > -Jeff
> > > > >
> > > > > > --- Jeff Brower
> > > wrote:
> > > > > >
> > > > > > > Michael-
> > > > > > >
> > > > > > > > Till now I have been following the
> real
> > > first
> > > > > > > > imaginary second convention for
> > > representing
> > > > > > > complex
> > > > > > > > numbers -- Cause the dsplib functions
> for
> > > > > complex
> > > > > > > fft
> > > > > > > > stated so & much of Ti literature.
> > > > > > > >
> > > > > > > > a[0], a[1] -- where a[0] is real part
> &
> > > a[1]
> > > > > > > imaginary
> > > > > > > > part
> > > > > > > >
> > > > > > > > But now I came across CMPY instruction
> in
> > > > > c64+, so
> > > > > > > > though of replacing it with DOTP2 &
> DOTNP2
> > > > > pair.
> > > > > > > But,
> > > > > > > > its explanation seem to direct to
> > > imaginary
> > > > > first
> > > > > > > &
> > > > > > > > real second kind of ordering both for
> the
> > > > > inputs &
> > > > > > > for
> > > > > > > > the product.
> > > > > > > >
> > > > > > > > Can someone give me the reason behind
> this
> > > &
> > > > > also
> > > > > > > let
> > > > > > > > me know the right convention for c64
> > > > > architecture
> > > > > > > > [Tis literature seem to be confusing
> the
> > > > > reader,
> > > > > > > > clearly some places follow one
> convention
> > > &
> > > > > some
> > > > > > > the
> > > > > > > > other C different pages of the same
> > > document
> > > > > do
> > > > > > > have
> > > > > > > > this problem].
> > > > > > >
> > > > > > > It would be very unlikely after all
> these
> > > years
>
=== message truncated ==
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?pSTDEAL Start a New Thread

Michael-

You're avoiding the necessary low-level debug here. What are the actual physical
addresses? I looked in your map file and you didn't make the structure public so the
"Real" and "Imag" elements are not visible in the symbol information. You can use
"define symbols global" or similar option in CCS. You have to know the *actual
physical memory ordering* before you can say anything about what's really going on.

-Jeff
Michael Anburaj wrote:
>
> Jeff,
>
> I have included a sample project, which computes
> complex multiplication using CMPY instruction.
>
> 1. Inputs passed:
> A = 10+j30 & B = 20+j50
>
> 2. Expected results:
> C = 10*20-30*50 + j(10*50+30*20)
> C = -1300+j1100.
>
> 3. Results producted by cmpy:
> C = 1100+j1300
>
> Now if you consider Imaginary followed by real
> ordering in memory, Input can be rewritten as
> A = j10+30 & B = j20+50
>
> 4. Now the expected results:
> C = j(30*20+10*50)+30*50-10*20
> C = j1100+1300
>
> I havent explained it well, but hope its clear.
>
> Cheers,
> -Mike.
>
> C code:
> ======>
> typedef struct complex
> {
> short R;
> short I;
> }complex;
>
> complex A,B;
>
> typedef struct complex32
> {
> int R;
> int I;
> }complex32;
>
> complex32 C;
>
> int main(void)
> {
> A.R = 10;
> A.I = 30;
> B.R = 20;
> B.I = 50;
>
> complexMpy(A, B, C);
> }
>
> Assembly code:
> =============>
> .asg B15, B_SP
> .asg A4, A_pA
> .asg B4, B_pB
> .asg A6, A_pC
> .asg A7, A_A
> .asg B7, B_B
> .asg A8, A_Cr
> .asg A9, A_Ci
>
> .sect ".text:cmpy"
> .global _complexMpy
> _complexMpy:
>
> LDW .D2T2 *B_pB, B_B
> || LDW .D1T1 *A_pA, A_A
>
> NOP 4
>
> B .S2 B3
> || CMPY .M1X A_A, B_B, A_Ci:A_Cr
>
> NOP 3
>
> STDW .D1T1 A_Ci:A_Cr, *A_pC
>
> NOP
>
> --- Jeff Brower wrote:
>
> > Michael-
> >
> > > Input side:
> > > ==========> > >
> > > Structure (1) when accessed using 32bit or 64bit
> > load
> > > (little endian), Real will be lsb16 & Imaginary
> > will
> > > be msb16
> > >
> > > So, complex multiplication will yield the
> > following
> > > Real part:
> > >
> > > (lsb16(src1) lsb16(src2)) − (msb16(src1) br />
> >
> > > msb16(src2))
> > >
> > > Structure (2) when accessed using 32bit or 64bit
> > load
> > > (little endian), Real will be msb16 & Imaginary
> > will
> > > be lsb16
> > >
> > > So, complex multiplication will yield the
> > following
> > > Real part:
> > >
> > > (msb16(src1) msb16(src2)) − (lsb16(src1) br />
> >
> > > lsb16(src2))
> > >
> > > Now Output side:
> > > ==============> > > The output is 32bits, you are right about o (odd)
> > & e
> > > (even). Even is even number register & Odd is odd
> > > number register. When it is written into memory
> > (64bit
> > > access), even gets written 1st (Imaginary as per
> > the
> > > CMPY instruction) & then odd gets written next
> > (Real).
> > > So, it does Imaginary followed by Real ordering.
> > >
> > > Both Input & Output are in Imaginary followed by
> > Real
> > > ordering.
> > >
> > > Please let me know if you find anything wrong
> > here.
> >
> > Well, your first comment: "real is lsb16" -- that
> > means real is even and pair
> > ordering is real first, imag second. Again, this is
> > easy to resolve by just looking
> > at physical mem addresses. If the real value ends
> > up on even physical address, then
> > it's first in the pair.
> >
> > -Jeff
> >
> > > --- Jeff Brower wrote:
> > >
> > > > Michael-
> > > >
> > > > > Thanks for the info., and thats how I have
> > been
> > > > > coding (Sorry, I am very new to Tis world),
> > > > based on
> > > > > complex structure ordering (1).
> > > > >
> > > > > CMPY (.unit) src1, src2, dst_o:dst_e
> > instruction
> > > > in
> > > > > c64+ architecture does the following:
> > > > >
> > > > > SAT((lsb16(src1) msb16(src2)) +
> > (msb16(src1) br /> > > > > > lsb16(src2))) dst_e (Imag part)
> > > > > (msb 16(src1) msb16(src2)) −
> > (lsb16(src1)
> > > > br /> > > > > > lsb16(src2)) dst_o (Real part)
> > > > >
> > > > > This confirms that both input & output are
> > ordered
> > > > > like structure (2).
> > > >
> > > > Are you sure? "o" sounds like odd to me, and
> > "e"
> > > > even. What are the actual physical
> > > > addresses of struct1.Real and struct1.Imag if
> > you
> > > > look them up in the .map file?
> > > >
> > > > -Jeff
> > > >
> > > > > --- Jeff Brower
> > wrote:
> > > > >
> > > > > > Michael-
> > > > > >
> > > > > > > I am confused. Can you please let me know
> > the
> > > > > > correct
> > > > > > > ordering for R/I pair in memory for TI
> > > > > > architectures?
> > > > > > >
> > > > > > > Is it 1 or 2?
> > > > > > >
> > > > > > > 1.
> > > > > > > struct complex
> > > > > > > {
> > > > > > > short Real;
> > > > > > > Short Imag;
> > > > > > > };
> > > > > > >
> > > > > > > 2.
> > > > > > > struct complex
> > > > > > > {
> > > > > > > short Imag;
> > > > > > > Short Real;
> > > > > > > };
> > > > > >
> > > > > > First one.
> > > > > >
> > > > > > -Jeff
> > > > > >
> > > > > > PS. Please reply to the group. My job does
> > not
> > > > > > permit me to discuss outside the
> > > > > > group.
> > > > > >
> > > > > > -Jeff
> > > > > >
> > > > > > > --- Jeff Brower
> > > > wrote:
> > > > > > >
> > > > > > > > Michael-
> > > > > > > >
> > > > > > > > > Till now I have been following the
> > real
> > > > first
> > > > > > > > > imaginary second convention for
> > > > representing
> > > > > > > > complex
> > > > > > > > > numbers -- Cause the dsplib functions
> > for
> > > > > > complex
> > > > > > > > fft
> > > > > > > > > stated so & much of Ti literature.
> > > > > > > > >
> > > > > > > > > a[0], a[1] -- where a[0] is real part
> > &
> > > > a[1]
> > > > > > > > imaginary
> > > > > > > > > part
> > > > > > > > >
> > > > > > > > > But now I came across CMPY instruction
> > in
> > > > > > c64+, so
> > > > > > > > > though of replacing it with DOTP2 &
> > DOTNP2
> > > > > > pair.
> > > > > > > > But,
> > > > > > > > > its explanation seem to direct to
> > > > imaginary
> > > > > > first
> > > > > > > > &
> > > > > > > > > real second kind of ordering both for
> > the
> > > > > > inputs &
> > > > > > > > for
> > > > > > > > > the product.
> > > > > > > > >
> > > > > > > > > Can someone give me the reason behind
> > this
> > > > &
> > > > > > also
> > > > > > > > let
> > > > > > > > > me know the right convention for c64
> > > > > > architecture
> > > > > > > > > [Tis literature seem to be confusing
> > the
> > > > > > reader,
> > > > > > > > > clearly some places follow one
> > convention
> > > > &
> > > > > > some
> > > > > > > > the
> > > > > > > > > other C different pages of the same
> > > > document
> > > > > > do
> > > > > > > > have
> > > > > > > > > this problem].
> > > > > > > >
> > > > > > > > It would be very unlikely after all
> > these
> > > > years
> >
> === message truncated ==> Start a New Thread

Jeff,

I have included a sample project, which computes
complex multiplication using CMPY instruction.

1. Inputs passed:
A = 10+j30 & B = 20+j50

2. Expected results:
C = 10*20-30*50 + j(10*50+30*20)
C = -1300+j1100.

3. Results producted by cmpy:
C = 1100+j1300

Now if you consider Imaginary followed by real
ordering in memory, Input can be rewritten as
A = j10+30 & B = j20+50

4. Now the expected results:
C = j(30*20+10*50)+30*50-10*20
C = j1100+1300

I havent explained it well, but hope its clear.

Cheers,
-Mike.

C code:
======
typedef struct complex
{
short R;
short I;
}complex;

complex A,B;

typedef struct complex32
{
int R;
int I;
}complex32;

complex32 C;

int main(void)
{
A.R = 10;
A.I = 30;
B.R = 20;
B.I = 50;

complexMpy(A, B, C);
}
Assembly code:
=============
.asg B15, B_SP
.asg A4, A_pA
.asg B4, B_pB
.asg A6, A_pC
.asg A7, A_A
.asg B7, B_B
.asg A8, A_Cr
.asg A9, A_Ci

.sect ".text:cmpy"
.global _complexMpy
_complexMpy:

LDW .D2T2 *B_pB, B_B
|| LDW .D1T1 *A_pA, A_A

NOP 4

B .S2 B3
|| CMPY .M1X A_A, B_B, A_Ci:A_Cr

NOP 3

STDW .D1T1 A_Ci:A_Cr, *A_pC

NOP

--- Jeff Brower wrote:

> Michael-
>
> > Input side:
> > ==========> >
> > Structure (1) when accessed using 32bit or 64bit
> load
> > (little endian), Real will be lsb16 & Imaginary
> will
> > be msb16
> >
> > So, complex multiplication will yield the
> following
> > Real part:
> >
> > (lsb16(src1) lsb16(src2)) − (msb16(src1) br /> >
> > msb16(src2))
> >
> > Structure (2) when accessed using 32bit or 64bit
> load
> > (little endian), Real will be msb16 & Imaginary
> will
> > be lsb16
> >
> > So, complex multiplication will yield the
> following
> > Real part:
> >
> > (msb16(src1) msb16(src2)) − (lsb16(src1) br /> >
> > lsb16(src2))
> >
> > Now Output side:
> > ==============> > The output is 32bits, you are right about o (odd)
> & e
> > (even). Even is even number register & Odd is odd
> > number register. When it is written into memory
> (64bit
> > access), even gets written 1st (Imaginary as per
> the
> > CMPY instruction) & then odd gets written next
> (Real).
> > So, it does Imaginary followed by Real ordering.
> >
> > Both Input & Output are in Imaginary followed by
> Real
> > ordering.
> >
> > Please let me know if you find anything wrong
> here.
>
> Well, your first comment: "real is lsb16" -- that
> means real is even and pair
> ordering is real first, imag second. Again, this is
> easy to resolve by just looking
> at physical mem addresses. If the real value ends
> up on even physical address, then
> it's first in the pair.
>
> -Jeff
>
> > --- Jeff Brower wrote:
> >
> > > Michael-
> > >
> > > > Thanks for the info., and thats how I have
> been
> > > > coding (Sorry, I am very new to Tis world),
> > > based on
> > > > complex structure ordering (1).
> > > >
> > > > CMPY (.unit) src1, src2, dst_o:dst_e
> instruction
> > > in
> > > > c64+ architecture does the following:
> > > >
> > > > SAT((lsb16(src1) msb16(src2)) +
> (msb16(src1) br /> > > > > lsb16(src2))) dst_e (Imag part)
> > > > (msb 16(src1) msb16(src2)) −
> (lsb16(src1)
> > > br /> > > > > lsb16(src2)) dst_o (Real part)
> > > >
> > > > This confirms that both input & output are
> ordered
> > > > like structure (2).
> > >
> > > Are you sure? "o" sounds like odd to me, and
> "e"
> > > even. What are the actual physical
> > > addresses of struct1.Real and struct1.Imag if
> you
> > > look them up in the .map file?
> > >
> > > -Jeff
> > >
> > > > --- Jeff Brower
> wrote:
> > > >
> > > > > Michael-
> > > > >
> > > > > > I am confused. Can you please let me know
> the
> > > > > correct
> > > > > > ordering for R/I pair in memory for TI
> > > > > architectures?
> > > > > >
> > > > > > Is it 1 or 2?
> > > > > >
> > > > > > 1.
> > > > > > struct complex
> > > > > > {
> > > > > > short Real;
> > > > > > Short Imag;
> > > > > > };
> > > > > >
> > > > > > 2.
> > > > > > struct complex
> > > > > > {
> > > > > > short Imag;
> > > > > > Short Real;
> > > > > > };
> > > > >
> > > > > First one.
> > > > >
> > > > > -Jeff
> > > > >
> > > > > PS. Please reply to the group. My job does
> not
> > > > > permit me to discuss outside the
> > > > > group.
> > > > >
> > > > > -Jeff
> > > > >
> > > > > > --- Jeff Brower
> > > wrote:
> > > > > >
> > > > > > > Michael-
> > > > > > >
> > > > > > > > Till now I have been following the
> real
> > > first
> > > > > > > > imaginary second convention for
> > > representing
> > > > > > > complex
> > > > > > > > numbers -- Cause the dsplib functions
> for
> > > > > complex
> > > > > > > fft
> > > > > > > > stated so & much of Ti literature.
> > > > > > > >
> > > > > > > > a[0], a[1] -- where a[0] is real part
> &
> > > a[1]
> > > > > > > imaginary
> > > > > > > > part
> > > > > > > >
> > > > > > > > But now I came across CMPY instruction
> in
> > > > > c64+, so
> > > > > > > > though of replacing it with DOTP2 &
> DOTNP2
> > > > > pair.
> > > > > > > But,
> > > > > > > > its explanation seem to direct to
> > > imaginary
> > > > > first
> > > > > > > &
> > > > > > > > real second kind of ordering both for
> the
> > > > > inputs &
> > > > > > > for
> > > > > > > > the product.
> > > > > > > >
> > > > > > > > Can someone give me the reason behind
> this
> > > &
> > > > > also
> > > > > > > let
> > > > > > > > me know the right convention for c64
> > > > > architecture
> > > > > > > > [Tis literature seem to be confusing
> the
> > > > > reader,
> > > > > > > > clearly some places follow one
> convention
> > > &
> > > > > some
> > > > > > > the
> > > > > > > > other C different pages of the same
> > > document
> > > > > do
> > > > > > > have
> > > > > > > > this problem].
> > > > > > >
> > > > > > > It would be very unlikely after all
> these
> > > years
>
=== message truncated ==
____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/ Start a New Thread