topic Re: Entry code in Classic/Legacy CodeWarrior

Entry code

Sten — Wed, 17 May 2006 14:51:52 GMT

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?

Re: Entry code

CompilerGuru — Thu, 18 May 2006 04:45:12 GMT

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

Re: Entry code

Sten — Thu, 18 May 2006 12:43:48 GMT

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.

comp_test.zip

Message Edited by t.dowe on 2009-10-06 09:07 AM

Re: Entry code

CompilerGuru — Fri, 19 May 2006 15:16:16 GMT

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: