Entry code

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Entry code

3,844 Views
Sten
Contributor IV
CW for HC12 v. 4.5 build 6039
 
I have the following function:
void memfill(BYTE c) {    asm {  ldaa c
  ......    }    return;}

 This was by CW for HC12 v. 3.1 compiled to
PSHBLDAA 0,SP...PULARTC

 which did work, but v. 4.5 compiles to
LEAS -1,SPLDAA 0,SP...LEAS 1,SPRTC
 
which does not work because the function parameter 'c' does not get saved to the stack and thus the LDAA 0,SP will load something undefined.
 
I have in the same file an other routine which also returns the c-value, and that routine works on both versions.
 
This is clearly some kind of optimizing issue, but what optimization option could I use to get the PSHB back?
 
Labels (1)
0 Kudos
Reply
3 Replies

1,056 Views
CompilerGuru
NXP Employee
NXP Employee
can you provided a complete compilable sample?

When I just compiled the snippet you quoted, I do get the PSHB with V4.5. Please note also the exact options you use to compile.

With -Ot, the code is fine as well. And when not optimizing for time, I dont see why the compiler should use the larger (but faster) LEAS instead of a PSHB.
Daniel


412: typedef unsigned char BYTE;
413: void memfill(BYTE c) {
0000 37 [2] PSHB
414: asm {
415: ldaa c
0001 a680 [3] LDAA 0,SP
416: nop;
0003 a7 [1] NOP
417: }
418: return;
419: }
0004 32 [3] PULA
0005 3d [5] RTS
0 Kudos
Reply

1,056 Views
Sten
Contributor IV
I made a new project and added the two functions memfill() and memnchr() and they did work alright with the default options. Then I did copy the option string from my real project, and then the memfill() was faulty again. So it is some of my options that is causing this. Attached is the test-project which causes faulty code.
 
Can you please tell me which option do cause this.
Message Edited by t.dowe on 2009-10-06 09:07 AM
0 Kudos
Reply

1,056 Views
CompilerGuru
NXP Employee
NXP Employee
I see.
The problematic option is the -Ou (Optimize Dead Assignments).
Drop it from your command line, the resulting code is only different when HLI is present in a function, then the default (not specifying -ou/-onu) does not optimize this function.
But then -ou is present, it is optimized even though the dead assignment optimization is not aware of HLI. So the compiler takes the -ou as guarantee that no such access only by HLI case (as in yours) exists....

Daniel

PS: I did forward to the compiler team that the smart sliders do add this dangerous option automatically. So hopefully this silly behaviour will be fixed in the future.
Thanks for reporting :smileyhappy:
0 Kudos
Reply