|
|
View previous topic :: View next topic |
Author |
Message |
dave3 Guest
|
Odd PCM generated code |
Posted: Sun Apr 18, 2004 8:50 pm |
|
|
In the process of studying the PCM output for function pointers, I came across the following generated code, which appears redundant.
Code: |
.................... case 1:
.................... ret= fn1;
0013: MOVLW 00
0014: MOVWF 7A
0015: MOVLW 2B
0016: MOVWF 25
0017: MOVF 7A,W
0018: MOVWF 26
|
Since 7A isn't used anywhere else, why isn't a
used instead? Am I missing something? As you may infer, fn1() is at 002B. The variable 'ret' is the return value for a function which returns a pointer to one of two functions. 'ret' is declared an fptr, defined as:
Code: |
typedef int8 (*fptr)();
| Interestingly, if I tried returning the 'fn1' pointer directly from the switch statement, the compiler generates a warning. I'd be happy to post the entire .LST file if anyone's interested. Thanks for any insight. |
|
|
Ttelmah Guest
|
Re: Odd PCM generated code |
Posted: Mon Apr 19, 2004 2:05 am |
|
|
dave3 wrote: | In the process of studying the PCM output for function pointers, I came across the following generated code, which appears redundant.
Code: |
.................... case 1:
.................... ret= fn1;
0013: MOVLW 00
0014: MOVWF 7A
0015: MOVLW 2B
0016: MOVWF 25
0017: MOVF 7A,W
0018: MOVWF 26
|
Since 7A isn't used anywhere else, why isn't a
used instead? Am I missing something? As you may infer, fn1() is at 002B. The variable 'ret' is the return value for a function which returns a pointer to one of two functions. 'ret' is declared an fptr, defined as:
Code: |
typedef int8 (*fptr)();
| Interestingly, if I tried returning the 'fn1' pointer directly from the switch statement, the compiler generates a warning. I'd be happy to post the entire .LST file if anyone's interested. Thanks for any insight. |
Remember a pointer, is a two byte value. Though in your case, the address of fn1, is in the low bank, and hence the high byte is '0', this won't allways be the case. The compiler potentially could optimise this specific case (of a funtion in the low 256 bytes), to use a clrf for the high byte, but the code is generic, and transfers the high byte of the address, using a 'scratch' register (7A should be defined as 'scratch' if you look in the variable declaration listing).
Best Wishes |
|
|
dave3 Guest
|
|
Posted: Mon Apr 19, 2004 12:53 pm |
|
|
But why isn't the scratch register optimized away? |
|
|
|
|
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
|