|
|
View previous topic :: View next topic |
Author |
Message |
buchtsucht
Joined: 14 May 2010 Posts: 20
|
Why so many cycles to execute code with dspic30F |
Posted: Thu Jun 17, 2010 7:41 am |
|
|
Hi,
I am used to work with PICs like 12Fxx or 18Fxxx and have some rules of thumb, how much time some code needs to execute. As code get more complex, speed of dspic30F drecreases in a terrible way.
Did I have to use special comands to activate the fast DSP-functions of the dsPIC? I canĀ“t read assembler - so maybe somebody can give me a hint.
Code: | output_high(PIN_B3); | => 1 clock cycle ( as expected)
=> 3 clock cycles (expected 1 cycle)
Code: | aa+=( (int32)(bb-cc) * (int32)sin8[a] )>>6; | => 116 clock cycles (much too much! I have expected 10-15 cycles and calculate about 20-25 cycles for the only 8 bit wide 18F252)
Code: |
// cc=512;
030E 202004 mov.w #0x200,0x0008
0310 884064 mov.w 0x0008,0x080c
0312 EF280E clr.w 0x080e
// aa+=( (int32)(bb-cc) * (int32)sin8[a] )>>6;
0318 804044 mov.w 0x0808,0x0008
031A 804063 mov.w 0x080c,0x0006
031C 520283 sub.w 0x0008,0x0006,0x000a
031E 804054 mov.w 0x080a,0x0008
0320 804073 mov.w 0x080e,0x0006
0322 5A0303 subb.w 0x0008,0x0006,0x000c
0324 804000 mov.w 0x0800,0x0000
0326 020200 call 0x000200
032A EF6001 clr.b 0x0001
032C 200001 mov.w #0x0,0x0002
032E 780100 mov.w 0x0000,0x0004
0330 780181 mov.w 0x0002,0x0006
0332 780005 mov.w 0x000a,0x0000
0334 780086 mov.w 0x000c,0x0002
0336 02021C call 0x00021c
033A 780280 mov.w 0x0000,0x000a
033C 780301 mov.w 0x0002,0x000c
033E 200064 mov.w #0x6,0x0008
0340 780005 mov.w 0x000a,0x0000
0342 780086 mov.w 0x000c,0x0002
0344 E80204 inc.w 0x0008,0x0008
0346 E90204 dec.w 0x0008,0x0008
0348 320003 bra z, 0x000350
034A D10081 lsr.w 0x0002,0x0002
034C D38000 rrc.w 0x0000,0x0000
034E 37FFFB bra 0x000346
0350 B42804 add.w 0x0804
0352 780001 mov.w 0x0002,0x0000
0354 B48806 addc.w 0x0806,0x0000
0356 884030 mov.w 0x0000,0x0806 |
|
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Thu Jun 17, 2010 3:30 pm |
|
|
I'm not too familiar with the dsPIC, but I'd say you have to get your rules of thumb right.
The PIC18 is an 8 bit processor, the dsPIC is 16 bit. Being a 16 bit processor makes the dsPIC faster, but you can only compare the two when using their native bit sizes.
For example a 32-bit multiplication takes 228 cycles on a PIC18f458 and CCS compiler v4.077, not the 20-25 cycles you claim.
The whole expression takes 313 cycles on the PIC18, so the 116 for the dsPIC seem fine to me.
For fastest processing use 16-bit variables, not 32-bit!
The 3 instructions for the assignment I can't explain. Two are expected because you are moving a 32 bit variable on a 16 bit processor. But it seems like there is an unnecessary temp location used.
Again, use 16-bit variables!
What is your compiler version number? Newer versions can be expected to have improved efficiency. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Thu Jun 17, 2010 3:42 pm |
|
|
BTW,
Reading assembler is simply a matter of getting the datasheet (or in this case, the dataSHEETS that are the dsPIC family reference) and looking up the opcodes in the section that discussed the instruction set.
If you work with micro controllers, it's a good thing (almost invaluable) to be able to read code -- because sometimes library functions don't do what you want.
Might be your code.
Might be the compiler.
With new PIC's, I've helped CCS work out kinks in handling the new device because I've taken the time to learn the instruction set for PIC's.
It's not as hard as you think.
Cheers,
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Thu Jun 17, 2010 3:48 pm |
|
|
If you look on PDF page 354 of the dsPIC33F family reference, Table 25-2
You'll see there is no MOV instruction that allows #LIT to F
Only
MOV #LIT -> Wn
MOV Wn -> F
Now, your code shows this for a word (16bits) but I'm assuming you made CC a 32bit long word.
Soooo... if you look at the options, you can't set a 32bit literal.
So you could do
(2) 16bit words and then a double move or
(1) 16bit word, a move including a clear (your case)
(1) 16bit word, a clear, then a double move.
I bet if you change your 'cc=512' to something that uses both words, those instructions would change.
Try it out and see,
Cheers,
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
buchtsucht
Joined: 14 May 2010 Posts: 20
|
|
Posted: Fri Jun 18, 2010 11:05 pm |
|
|
Thanks!
With your help, I found the (idiotic) mistake - I have forgotten:
8 Bit PIC => INT= 8Bit
16 Bit Pic => INT= 16 Bit
Additional the CCS compiler for dspic could be better. But playing a little bit with my C-code (having the PIC-functions in mind), I get the expected speed for DSP. |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sat Jun 19, 2010 2:09 am |
|
|
Quote: | I have expected 10-15 cycles and calculate about 20-25 cycles for the only 8 bit wide 18F252 |
That's completely illusional for 32 bit arithmetics, in both cases.
Quote: | Additional the CCS compiler for dspic could be better. |
Based on an analysis of PCD optimization strategy, I would agree. But I wonder what are your criteria in this regard? You confessed not to understand the assembly listing and apparently didn't consider the specific dsPIC architecture properties. How do you know?
A detailed analysis shows, that PCD is actually processing the C code too much "line-by-line", it's reading the code like a abecedarian does in his reading primer. As a result, it is performing many avoidable register and temporary variable loads. I think however, that CCS acted wisely when not trying more optimization, because handling many general purpose registers caused a lot of confusion in previous PCD releases. Some bugs with complex 32-bit expressions have been continued til today...
Another option to achieve faster arithmetic particulary with dSPIC is to utilize the DSP instruction set. But unfortunately PCD can't infer it from C code. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|