|
Hi all, We are working with c54x. The 'c' code which we have written is not any architecture specific. We first tested it in c54x simulator with the gel file meant for 5402. It worked with that. Then we tried with gel file for 5409 as well. It worked. But, not always in both cases. There is no change in the code and the linker command file. There is a function which is called by main which inturn calls another function. Now, most of the times, when we compile it, the ALP (disassembly) corresponding the the start of that function (the third one), seems to be different. Most of the times, it's giving out one set of instructions which don't have any desired impact at all. It's as though the program has lost all it's memory when it comes down to that part of the code. (losing the value of the parameters we try to pass in) The few times it gives out the correct set of alp, it works fine.(in the simulator) When we tried with the board, it never generated the correct set of instructions. This particular function takes in two parameters from the other function which calls it. And these two variables don't get assigned with the right values when this function is entered. We are using CCS version 2.00 for this. The following is the wrong set of ALP instructions which makes the program go wrong (at the beginning of the third function) a += @0h sp += -8 b = b + *ar5+0 <<16 a += *+ar3(16384)% <<TS The following is the set of ALP which we sometimes got (rightly) when we complied (the above one and this one had no diff. settings or anything like that) push(mmr(11h)) sp += -8 nop @2h = A ==> This set gives out the desired execution of the program. We want to know why is there a difference in the ALP generated when the code and the linker command files are exactly the same. Anybody with any ideas pl. inform us ... will be real useful to us...thanks for reading through..... C.Ganesh Kumar & N.Haribabu. |
|
|
inconsistent ALP generation with the same code (CCS Ver 2.0)
Started by ●June 2, 2003
Reply by ●June 2, 20032003-06-02
|
This is quite interesting. What if you change the C compiler to generate the Mnemonic instruction set instead of Algebraic, and see if the generated result is consistence or not?? At least this way you can prove if this is caused by the generation tools. Optimization setting may also contribute to this issue, but not always. Maybe you can create a small program that can regenerate this problem, and share with us. Ben -------- Ganesh Kumar C <> wrote:Hi all, We are working with c54x. The 'c' code which we have written is not any architecture specific. We first tested it in c54x simulator with the gel file meant for 5402. It worked with that. Then we tried with gel file for 5409 as well. It worked. But, not always in both cases. There is no change in the code and the linker command file. There is a function which is called by main which inturn calls another function. Now, most of the times, when we compile it, the ALP (disassembly) corresponding the the start of that function (the third one), seems to be different. Most of the times, it's giving out one set of instructions which don't have any desired impact at all. It's as though the program has lost all it's memory when it comes down to that part of the code. (losing the value of the parameters we try to pass in) The few times it gives out the correct set of alp, it works fine.(in the simulator) When we tried with the board, it never generated the correct set of instructions. This particular function takes in two parameters from the other function which calls it. And these two variables don't get assigned with the right values when this function is entered. We are using CCS version 2.00 for this. The following is the wrong set of ALP instructions which makes the program go wrong (at the beginning of the third function) a += @0h sp += -8 b = b + *ar5+0 <<16 a += *+ar3(16384)% < The following is the set of ALP which we sometimes got (rightly) when we complied (the above one and this one had no diff. settings or anything like that) push(mmr(11h)) sp += -8 nop @2h = A ==> This set gives out the desired execution of the program. We want to know why is there a difference in the ALP generated when the code and the linker command files are exactly the same. Anybody with any ideas pl. inform us ... will be real useful to us...thanks for reading through..... C.Ganesh Kumar & N.Haribabu. _____________________________________ 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: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://www.yahoogroups.com/group/c54x Other Groups: http://www.dsprelated.com ">http://docs.yahoo.com/info/terms/ __________________________________ |
Reply by ●June 3, 20032003-06-03
|
Hi all, dear ben, thanks for replying. This is for your questions. 1. "change the C compiler to generate the Mnemonic instruction set instead of Algebraic, and see It is the same case with Mnemonic instruction set also." Mnemonic instruction set is also different. 2. The optimization level is at 0. There is no optimization at all. We tried something else today. First our program was written in the following manner. The functions were defined directly before main() instead of declaring the prototypes and then the main() and then the function definitions. void func1(parameters) { } void func2(parameters) { } ........... void main() { } The strange thing happening was that that problem was occuring only with the first function after the external variables declaration. We tried swapping the first two functions positions, but again, the first function (which was previously the second) now had the same problem. So, what we did now was that we just gave the function prototypes (instead of defining the functions at the beginning) and then it was followed by main() and then the code had all other functions defined. Now, we are currently checking the same in the c5409 simulator. As of now, it seems to be running fine. Is there anything wrong in defining the functions directly at the beginning instead of giving the prototypes and then at the end, defining the functions. C.Ganesh Kumar & N.Haribabu. >>> Benjamin Chan <> 06/02/03 08:10PM >>> This is quite interesting. What if you change the C compiler to generate the Mnemonic instruction set instead of Algebraic, and see if the generated result is consistence or not?? At least this way you can prove if this is caused by the generation tools. Optimization setting may also contribute to this issue, but not always. Maybe you can create a small program that can regenerate this problem, and share with us. Ben -------- Ganesh Kumar C <> wrote:Hi all, We are working with c54x. The 'c' code which we have written is not any architecture specific. We first tested it in c54x simulator with the gel file meant for 5402. It worked with that. Then we tried with gel file for 5409 as well. It worked. But, not always in both cases. There is no change in the code and the linker command file. There is a function which is called by main which inturn calls another function. Now, most of the times, when we compile it, the ALP (disassembly) corresponding the the start of that function (the third one), seems to be different. Most of the times, it's giving out one set of instructions which don't have any desired impact at all. It's as though the program has lost all it's memory when it comes down to that part of the code. (losing the value of the parameters we try to pass in) The few times it gives out the correct set of alp, it works fine.(in the simulator) When we tried with the board, it never generated the correct set of instructions. This particular function takes in two parameters from the other function which calls it. And these two variables don't get assigned with the right values when this function is entered. We are using CCS version 2.00 for this. The following is the wrong set of ALP instructions which makes the program go wrong (at the beginning of the third function) a += @0h sp += -8 b = b + *ar5+0 <<16 a += *+ar3(16384)% < The following is the set of ALP which we sometimes got (rightly) when we complied (the above one and this one had no diff. settings or anything like that) push(mmr(11h)) sp += -8 nop @2h = A ==> This set gives out the desired execution of the program. We want to know why is there a difference in the ALP generated when the code and the linker command files are exactly the same. Anybody with any ideas pl. inform us ... will be real useful to us...thanks for reading through..... _____________________________________ 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: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://www.yahoogroups.com/group/c54x Other Groups: http://www.dsprelated.com ">http://docs.yahoo.com/info/terms/ __________________________________ _____________________________________ 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: Send an email to To Post: Send an email to To Leave: Send an email to Archives: http://www.yahoogroups.com/group/c54x Other Groups: http://www.dsprelated.com ">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●June 3, 20032003-06-03
|
I never met this problem with the tools before (maybe someone did). I did try with a test program and didn't see the tools doing funny things like what you are describing. There is one possibility that the declared external variables (or other macros and defines) just before the first function got the compiler tools confused. That is my best guess. BTW, my tools is version 2.1. In any case, if moving the functions around can solve the problem, leave it the way it is. Or just move the rest of the functions to other files instead. Good luck. Ben --- Ganesh Kumar C <> wrote: > Hi all, > > dear ben, thanks for replying. This is for your > questions. > > 1. "change the C compiler to generate the > Mnemonic instruction set > instead of Algebraic, and see It is the same case > with Mnemonic > instruction set also." > > Mnemonic instruction set is also different. > > 2. The optimization level is at 0. There is no > optimization at > all. > > We tried something else today. First our program > was written in the > following manner. The functions > were defined directly before main() instead of > declaring the prototypes > and then the main() and then the > function definitions. > > void func1(parameters) > { > } > void func2(parameters) > { > } > ........... > void main() > { > > } > > The strange thing happening was that that problem > was occuring only > with the first function > after the external variables declaration. We tried > swapping the first > two functions positions, but > again, the first function (which was previously the > second) now had the > same problem. > > So, what we did now was that we just gave the > function prototypes (instead of defining the > functions at the > beginning) and then it was > followed by main() and then the code had all other > functions defined. > > Now, we are currently checking the same in the > c5409 simulator. As > of now, it seems to be > running fine. Is there anything wrong in defining > the functions > directly at the beginning instead of > giving the prototypes and then at the end, defining > the functions. > C.Ganesh Kumar & N.Haribabu. > > >>> Benjamin Chan <> 06/02/03 > 08:10PM >>> > This is quite interesting. What if you change the C > compiler to generate the Mnemonic instruction set > instead of Algebraic, and see if the generated > result > is consistence or not?? > > At least this way you can prove if this is caused by > the generation tools. Optimization setting may also > contribute to this issue, but not always. > > Maybe you can create a small program that can > regenerate this problem, and share with us. > > Ben > > -------- > Ganesh Kumar C <> > wrote:Hi > all, > > We are working with c54x. The 'c' code which we have > written is not > any architecture specific. > > We first tested it in c54x simulator with the gel > file > meant for 5402. > It worked with that. Then we tried with gel file for > 5409 as well. It > worked. But, not always in both cases. There is no > change in the code > and the linker command file. > > There is a function which is called by main which > inturn calls another > function. Now, most of the times, when we compile > it, > the ALP > (disassembly) corresponding the the start of that > function (the third > one), seems to be different. Most of the times, it's > giving out one > set of instructions which don't have any desired > impact at all. It's as > though the program has lost all it's memory when it > comes down to that > part of the code. > (losing the value of the parameters we try to pass > in) > > The few times it gives out the correct set of alp, > it > works > fine.(in the simulator) > > When we tried with the board, it never generated the > correct set of > instructions. > > This particular function takes in two parameters > from > the other > function which calls it. And these two variables > don't > get assigned > with the right values when this function is entered. > > We are using CCS version 2.00 for this. > > The following is the wrong set of ALP instructions > which makes the > program go wrong (at the beginning of the third > function) > > a += @0h > sp += -8 > b = b + *ar5+0 <<16 > a += *+ar3(16384)% < > The following is the set of ALP which we sometimes > got > (rightly) > when we complied (the above one and this one had no > diff. settings or > anything like that) > > push(mmr(11h)) > sp += -8 > nop > @2h = A ==> This set gives out the desired execution > of the > program. > > We want to know why is there a difference in the ALP > generated when > the code and the linker command files are exactly > the > same. > > Anybody with any ideas pl. inform us ... will be > real > useful to > us...thanks for reading through..... > _____________________________________ > 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: Send an email to > To Post: Send an email to > > To Leave: Send an email to > Archives: http://www.yahoogroups.com/group/c54x > > Other Groups: http://www.dsprelated.com > ">http://docs.yahoo.com/info/terms/ === message truncated === __________________________________ |
