Bug report: HC12 Compiler 5.0.35 will erroneously inline routines with assembly code

[adiroot]

HC12 Compiler 5.0.35 will erroneously inline routines with assembly code.

We switched from version 5.0.21  to 5.0.35 of the HC12 compiler.  A C routine that had assembly code in it was not inlined by compiler 5.0.21.  However, 5.0.35 did inline the routine, and did so poorly, resulting in a bug (stack mixup causing variable values to be written in the wrong place).

Here's the C code:

#pragma INLINE
char SpiByteExchange(register unsigned char cDataToSend)
{
   while (SPI1SR_SPTEF == 0);
   asm STAB SPI1DR;
   while (SPI1SR_SPIF == 0);
   return SPI1DR;
}

Here's the assembly from compiler 5.0.35:

Options : -C++f -Cf -Cni -CpEPAGE -CpGPAGE -CpPPAGE -CpRPAGE -CPUHCS12X -DSDRX -F2 -Lasm=%n.lst -Lasmc=aepv -Ldf=predef.h -Lm=d:\SDRX\text\SDRX.dep -Ml -Onu -Onf -Oi=c0 -OnB -Onbt -Onca -Oncn -One -OnP=abcdefghijklmnpqrtu -Ont= -TuCD4LD4LLD4uE -ViewHidden -W1 -WErrFileOff -WmsgNu=abcde -WmsgSd1106 -WmsgSd1435 -WOutFileOn

  513:    SpiByteExchange(0xff);
  c6ff         [1]     LDAB  #255
  6b8c         [2]     STAB  12,SP
  4f0020fc     [4]     BRCLR _SPI1SR,#32,*+0 ;abs = 0012
  5b00         [2]     STAB  _SPI1DR
  4f0080fc     [4]     BRCLR _SPI1SR,#128,*+0 ;abs = 0018
  d600         [3]     LDAB  _SPI1DR

[CompilerGuru]

>However, 5.0.35 did inline the routine, and did so poorly, resulting in a

> bug (stack mixup causing variable values to be written in the wrong place).

When looking at the code I see a store to SP+12. Are you sure that is not just where the (never read) cDataToSend is stored to?  As -Onu is used (don't optimize unused stores) this seems reasonable to me.

Just looking at the code I'm not sure it is actually wrong.

The shown SpiByteExchange is on the other hand explicitly marked with a #pragma INLINE. I well would think inlining it is the right thing to do. Not inlining it is probably as easy as not using that pragma...

BTW: The routine assumes that the B register is not modified by the C code before. I don't think this is guaranteed. While the existing simple while loop might not touch B, I don't think compiler would preserve it if some other C patter would write to B. So that STAB is a bit on the dangerous side, especially with inlining where the store to the unused local variable is a bit pointless....

Daniel

[adiroot]

Hi Daniel and thanks for your reply.

I think that you are correct in saying that the bug caused by the combination of the STAB instruction and the #pragma INLINE.  I should not be doing one or the other.

However The issue that I am reporting is this:

"Compiler is inlining routines that have assembly code in them".

 Previous versions of the compiler did not have this bug and did not inline the code.  That was easy enough to check by looking at the assembly listing.  The manual says that functions with inline assembly statements are not inlined (pg 239)

HC(S)12 Build Tools Reference Manual Revised: 3 April 2008

I am using -Oi=0 and a pragma inline, so mea culpa in this case for trying to inline the routine.   However, other programmers that are using the -Oi option (which inlines all routines of less than 40 bytes) and switching to the newer version of the compiler may run into the same bug. 

I think that a fix is needed.  Or an update of the manual.

[CompilerGuru]

Reporting the issue as documentation bug makes sence, absolutely.

>I am using -Oi=0 and a pragma inline, so mea culpa in this case for trying to inline the routine.  

> However, other programmers that are using the -Oi option (which inlines all routines of less than 40 bytes)

> and switching to the newer version of the compiler may run into the same bug.

Just using -Oi=40 will not inline functions with HLI. Functions containing HLI code are only inlined if they contain an explicit  #pragma INLINE.

Daniel