<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic DSC inline assembler mismanages access to upper 4bits of 36bit accumulator registers in Digital Signal Controllers</title>
    <link>https://community.nxp.com/t5/Digital-Signal-Controllers/DSC-inline-assembler-mismanages-access-to-upper-4bits-of-36bit/m-p/1336182#M2246</link>
    <description>&lt;P&gt;I've found an issue in the inline assembler.&lt;/P&gt;&lt;P&gt;When compiling the following code:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;typedef unsigned char       UINT8;
typedef unsigned int        UINT16;
typedef unsigned long       UINT32;

typedef struct UINT64_T {
	UINT32 low32;
	UINT32 high32;
}  UINT64;

/* compile with -signed-char */
typedef signed char         SINT8;
typedef signed int          SINT16;
typedef signed long         SINT32;

// typedef signed long long    SINT64;
typedef struct SINT64_T {
	UINT32 low32;
	SINT32 high32;
}  SINT64;
 
typedef UINT64 RRTCTime; // 8Khz timer tick counter

typedef struct ITEMS_TIME_STRUCT
{
	UINT64 mSecEpoch; // milliseconds since 1/1/1970
	UINT8  flags;
	BYTE dummy_alignment_byte1;
	BYTE dummy_alignment_byte2;
	BYTE dummy_alignment_byte3;
} iTEMSTime;

inline void u64_SHR3(register UINT64 *RReg )
{
	register UINT32 AA;
	register UINT32 BB;
	__asm{
	move.l X:(RReg)+,AA
	move.l X:(RReg),BB
	move.w #0,BB.2 // clear extension, so "asr BB" will be like "lsr BB10"
	asr BB
	ror.l AA
	asr BB
	ror.l AA
	asr BB
	ror.l AA
	move.l BB,X:(RReg)-
	move.l AA,X:(RReg)
	}
}
inline void u64_add_S16(register UINT64 *R2Reg, register SINT16 D16)
{
	// N.B. by declaring "register UINT32 XReg;"
	// into assembly istructions you can use
	// Xreg   --&amp;gt; 32bit register   (either dst A,B,C,D or src A10,B10,C10,D10)
	// Xreg.0 --&amp;gt; lower 16bit word (either A0,B0,C0,D0)
	// Xreg.1 --&amp;gt; upper 16bit word (either A1,B1,C1,D1)

	// *R2reg = *R3Reg + BB
	__asm{
		adda #2,SP
		move.l Y,X:(SP)+
		move.l A10,X:(SP)
		move.w D16,Y0
		move.w #0,Y1 // this is necessary to tell the compiler that register Y is in use
	    move.l X:(R2Reg),A
		tst.w  Y0
		blt    do_sub_s16
		add    Y,A
		move.l A10,X:(R2Reg)+
		move.l #0,Y
		move.l X:(R2Reg),A
		adc    Y,A
		bra    end_add_s16
	do_sub_s16:
		neg    Y0
		sub    Y,A
		move.l A10,X:(R2Reg)+
		move.l #0,Y
		move.l X:(R2Reg),A
		sbc    Y,A
	end_add_s16:
		move.l A10,X:(R2Reg)-
		move.l X:(SP)-,A
		move.l X:(SP)-,Y
	};
}

#define tick2mSec(tmp) {u64_SHR3(tmp);} // myRTC/8 --&amp;gt; time in mSec

void iTEMSTimeFromRRTC(iTEMSTime *p, int fixup)
{
	register RRTCTime *pTime;
	// fixup is time offset in 8KHz ticks
	// to compensate for transmission/reception delays
	pTime = &amp;amp;(p-&amp;gt;mSecEpoch);

	u64_add_S16(pTime,fixup);

        // convert from 8kHz ticks to milliseconds
	tick2mSec(pTime);

	p-&amp;gt;flags = 0;
}&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Compiler's inline assembler mismanages BB.2 references like this (example from the disassembly of the inline code generated by expanding u64_shr3() inside iTEMSTimeFromRRTC() &lt;LI-EMOJI id="lia_disappointed-face" title=":disappointed_face:"&gt;&lt;/LI-EMOJI&gt;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;0x0000002C  0xF120                 move.l      X:(R0)+,B
0x0000002D  0xF034                 move.l      X:(R0),A
0x0000002E  0xE080                 move.w      #0,A
0x0000002F  0x706B                 asr         A
0x00000030  0x76C7                 ror.l       B
0x00000031  0x706B                 asr         A
0x00000032  0x76C7                 ror.l       B
0x00000033  0x706B                 asr         A
0x00000034  0x76C7                 ror.l       B
0x00000035  0xD030                 move.l      A10,X:(R0)-
0x00000036  0xD134                 move.l      B10,X:(R0)&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;That is the sequence of assembly instructions:&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;	register UINT32 AA;
	register UINT32 BB;
	__asm{
	      move.l X:(RReg)+,AA
	      move.l X:(RReg),BB
	      move.w #0,BB.2 // clear extension, so "asr BB" will be like "lsr BB10"
              ...
        }&lt;/LI-CODE&gt;&lt;P&gt;Gets assembled as:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;0x0000002C  0xF120                 move.l      X:(R0)+,B
0x0000002D  0xF034                 move.l      X:(R0),A
0x0000002E  0xE080                 move.w      #0,A&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;register variable AA gets mapped into B accumulator, BB gets mapped into A accumulator&lt;BR /&gt;(so far, so good)&lt;BR /&gt;but the inline assembly instruction&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;FONT color="#0000FF"&gt;move.w #0,&lt;STRONG&gt;BB.2&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;instead of being assembled as&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;FONT color="#008000"&gt;move.w #0,&lt;STRONG&gt;A2&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;gets "wrongtimized" (optimized in a wrong way) as:&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;FONT color="#FF0000"&gt;move.w #0,&lt;STRONG&gt;A&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;STRONG&gt;Clearing A0, A1 and A2&lt;/STRONG&gt; instead of only clearing A2.&lt;/P&gt;&lt;P&gt;I fixed the issue on my own by changing the inline source assembly code, but such bugs at assembler level should not exist in a mature toolchain like this.&lt;/P&gt;</description>
    <pubDate>Tue, 07 Sep 2021 14:22:35 GMT</pubDate>
    <dc:creator>Lorenzo_Mch_IT</dc:creator>
    <dc:date>2021-09-07T14:22:35Z</dc:date>
    <item>
      <title>DSC inline assembler mismanages access to upper 4bits of 36bit accumulator registers</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/DSC-inline-assembler-mismanages-access-to-upper-4bits-of-36bit/m-p/1336182#M2246</link>
      <description>&lt;P&gt;I've found an issue in the inline assembler.&lt;/P&gt;&lt;P&gt;When compiling the following code:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;typedef unsigned char       UINT8;
typedef unsigned int        UINT16;
typedef unsigned long       UINT32;

typedef struct UINT64_T {
	UINT32 low32;
	UINT32 high32;
}  UINT64;

/* compile with -signed-char */
typedef signed char         SINT8;
typedef signed int          SINT16;
typedef signed long         SINT32;

// typedef signed long long    SINT64;
typedef struct SINT64_T {
	UINT32 low32;
	SINT32 high32;
}  SINT64;
 
typedef UINT64 RRTCTime; // 8Khz timer tick counter

typedef struct ITEMS_TIME_STRUCT
{
	UINT64 mSecEpoch; // milliseconds since 1/1/1970
	UINT8  flags;
	BYTE dummy_alignment_byte1;
	BYTE dummy_alignment_byte2;
	BYTE dummy_alignment_byte3;
} iTEMSTime;

inline void u64_SHR3(register UINT64 *RReg )
{
	register UINT32 AA;
	register UINT32 BB;
	__asm{
	move.l X:(RReg)+,AA
	move.l X:(RReg),BB
	move.w #0,BB.2 // clear extension, so "asr BB" will be like "lsr BB10"
	asr BB
	ror.l AA
	asr BB
	ror.l AA
	asr BB
	ror.l AA
	move.l BB,X:(RReg)-
	move.l AA,X:(RReg)
	}
}
inline void u64_add_S16(register UINT64 *R2Reg, register SINT16 D16)
{
	// N.B. by declaring "register UINT32 XReg;"
	// into assembly istructions you can use
	// Xreg   --&amp;gt; 32bit register   (either dst A,B,C,D or src A10,B10,C10,D10)
	// Xreg.0 --&amp;gt; lower 16bit word (either A0,B0,C0,D0)
	// Xreg.1 --&amp;gt; upper 16bit word (either A1,B1,C1,D1)

	// *R2reg = *R3Reg + BB
	__asm{
		adda #2,SP
		move.l Y,X:(SP)+
		move.l A10,X:(SP)
		move.w D16,Y0
		move.w #0,Y1 // this is necessary to tell the compiler that register Y is in use
	    move.l X:(R2Reg),A
		tst.w  Y0
		blt    do_sub_s16
		add    Y,A
		move.l A10,X:(R2Reg)+
		move.l #0,Y
		move.l X:(R2Reg),A
		adc    Y,A
		bra    end_add_s16
	do_sub_s16:
		neg    Y0
		sub    Y,A
		move.l A10,X:(R2Reg)+
		move.l #0,Y
		move.l X:(R2Reg),A
		sbc    Y,A
	end_add_s16:
		move.l A10,X:(R2Reg)-
		move.l X:(SP)-,A
		move.l X:(SP)-,Y
	};
}

#define tick2mSec(tmp) {u64_SHR3(tmp);} // myRTC/8 --&amp;gt; time in mSec

void iTEMSTimeFromRRTC(iTEMSTime *p, int fixup)
{
	register RRTCTime *pTime;
	// fixup is time offset in 8KHz ticks
	// to compensate for transmission/reception delays
	pTime = &amp;amp;(p-&amp;gt;mSecEpoch);

	u64_add_S16(pTime,fixup);

        // convert from 8kHz ticks to milliseconds
	tick2mSec(pTime);

	p-&amp;gt;flags = 0;
}&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Compiler's inline assembler mismanages BB.2 references like this (example from the disassembly of the inline code generated by expanding u64_shr3() inside iTEMSTimeFromRRTC() &lt;LI-EMOJI id="lia_disappointed-face" title=":disappointed_face:"&gt;&lt;/LI-EMOJI&gt;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;0x0000002C  0xF120                 move.l      X:(R0)+,B
0x0000002D  0xF034                 move.l      X:(R0),A
0x0000002E  0xE080                 move.w      #0,A
0x0000002F  0x706B                 asr         A
0x00000030  0x76C7                 ror.l       B
0x00000031  0x706B                 asr         A
0x00000032  0x76C7                 ror.l       B
0x00000033  0x706B                 asr         A
0x00000034  0x76C7                 ror.l       B
0x00000035  0xD030                 move.l      A10,X:(R0)-
0x00000036  0xD134                 move.l      B10,X:(R0)&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;That is the sequence of assembly instructions:&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;	register UINT32 AA;
	register UINT32 BB;
	__asm{
	      move.l X:(RReg)+,AA
	      move.l X:(RReg),BB
	      move.w #0,BB.2 // clear extension, so "asr BB" will be like "lsr BB10"
              ...
        }&lt;/LI-CODE&gt;&lt;P&gt;Gets assembled as:&lt;/P&gt;&lt;LI-CODE lang="c"&gt;0x0000002C  0xF120                 move.l      X:(R0)+,B
0x0000002D  0xF034                 move.l      X:(R0),A
0x0000002E  0xE080                 move.w      #0,A&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;register variable AA gets mapped into B accumulator, BB gets mapped into A accumulator&lt;BR /&gt;(so far, so good)&lt;BR /&gt;but the inline assembly instruction&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;FONT color="#0000FF"&gt;move.w #0,&lt;STRONG&gt;BB.2&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;instead of being assembled as&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;FONT color="#008000"&gt;move.w #0,&lt;STRONG&gt;A2&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;gets "wrongtimized" (optimized in a wrong way) as:&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;FONT color="#FF0000"&gt;move.w #0,&lt;STRONG&gt;A&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;STRONG&gt;Clearing A0, A1 and A2&lt;/STRONG&gt; instead of only clearing A2.&lt;/P&gt;&lt;P&gt;I fixed the issue on my own by changing the inline source assembly code, but such bugs at assembler level should not exist in a mature toolchain like this.&lt;/P&gt;</description>
      <pubDate>Tue, 07 Sep 2021 14:22:35 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/DSC-inline-assembler-mismanages-access-to-upper-4bits-of-36bit/m-p/1336182#M2246</guid>
      <dc:creator>Lorenzo_Mch_IT</dc:creator>
      <dc:date>2021-09-07T14:22:35Z</dc:date>
    </item>
    <item>
      <title>Re: DSC inline assembler mismanages access to upper 4bits of 36bit accumulator registers</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/DSC-inline-assembler-mismanages-access-to-upper-4bits-of-36bit/m-p/1336403#M2247</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;Thank you for pointing out the bug.&lt;/P&gt;
&lt;P&gt;I will report the bug to corresponding team.&lt;/P&gt;
&lt;P&gt;BR&lt;/P&gt;
&lt;P&gt;XiangJun Rong&lt;/P&gt;</description>
      <pubDate>Wed, 08 Sep 2021 02:24:58 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/DSC-inline-assembler-mismanages-access-to-upper-4bits-of-36bit/m-p/1336403#M2247</guid>
      <dc:creator>xiangjun_rong</dc:creator>
      <dc:date>2021-09-08T02:24:58Z</dc:date>
    </item>
  </channel>
</rss>

