Codewarrior Inline assembly hc12

[MOTCPU]

I have a small C function with input far pointers and ints, and returns a char value 1 or 0.

It is compiled and to create an assembly listing.

The c code in function is then commented out and a slightly modified inline assembly from lst file inserted in the function.

This executed code seems to work, however the compiler states warning that, return expected and parameters declared in function but not used.

What is required to ensure it will always work correctly and to clean up these warnings.

//------------------------------------------------------------------------
char cFarCmp(unsigned char *__far24 cpFarCurBlk,
       unsigned char *__far24 cpFarBlkStart,
       unsigned long lFsize)
{ 

#if 0
  if(cpFarCurBlk < (cpFarBlkStart+lFsize)) return 0;
  return 1; 

#else

  __asm {

     PSHD 
          PSHX 
//if(cpFarCurBlk < (cpFarBlkStart+lFsize)) return 0;
          PSHD 
         LDAB  3,SP
          PSHB 
          LDX   11,SP
         LDAA  10,SP
        JSR   tpPADD
         LDY   11,SP
          PSHA 
         LDAA  11,SP
          PULB 
        JSR   tpFPCMP
          BCC   *+4 ;abs = 001a
          CLRB
          BRA  FARCMP1
//return 1; 
     LDAB  #1
FARCMP1:
         LEAS  4,SP
     RTC  
     }

}
//------------------------------------------------------------------------

[bigmac]

Hello, and welcome to the forum.

The compiler generates the warnings because your function code does not use the parameter names, nor does explicitly return a value prior to exit.  The function works because you are reading the required values directly from the registers and stack, in accordance with the normal calling convention, and are exiting with the required value in the appropriate return register.  However, the compiler does not recognise this is what you are doing within your inline code.

To avoid the warnings, the inline code would need to read each of the parameter variables using the parameter name.  The return value might be written to a temporary variable just prior to completing the inline block.  The function can then finish with the C code return temp; which would also utilise the compiler to terminate the function, rather than inline code.

If the inline code is based on that which the compiler generates, there would seem little point in explicitly using assembly code.  It would seem that there are no efficiencies to be gained in code size or speed, and the code would be non-portable to other MCU families.

Regards,

Mac

[MOTCPU]

The assembly code arises, because the C functions erases and programs new firmware into the cpu flash.

The C code compiles to assembly which accesses the library functions in Block1 in HCS12 CPU.

Thus when erasing BLOCK1 from flash program located in BLOCK2, causes the program to terminate.

Therfore the flash program assembly code is modified to call a copy of a renamed library file within BLOCK2.

I previously looked at returning a C variable, however it generates other unwanted lib calls.

If there was a setting in CW, then it would have been good quick solution.

Only concern was if CW compiler is going to do something, because passed variables are not used in the function.

"To avoid the warnings, the inline code would need to read each of the parameter variables using the parameter name."

How exactly, is this done in the inline assembly code, as it is just uses the stack variables?

CW says dont mix HLI with C declarations, which is why complete function is HLI.

Is there an example somewhere?

Thanks

Terry

[Navidad · Accepted solution]

Hello MOTCPU,

There is a chapter in the compiler manual named "Mixing HLI Assembly and HLL" and there are also some examples included there. Also, inline assembly is extensively used in the runtime library, so you can use the library itself as example. For the particular situation you are describing you can simply ignore the warnings. Wherever this function is called in your code the compiler will stick to the calling convention, no matter what is the content of the function itself, so you don't need to worry about that. However, since you are replacing all the code within the function, it would be best to add #pragma NO_ENTRY and #pragma NO_EXIT before the function. If required, there are options to disable the warning.