<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/17244/c51-compiler-bug-help-please</link><description> I catch a C51 compiler bug when debugging some functions to calculate time differrence. 
The main function&amp;#39;s prints out shows that function DifferExStamp(T1,T2) give error time differrence, but DifferJDxTime(djT1,djT2) give correct results. 
When I check</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/141359?ContentTypeID=1</link><pubDate>Mon, 09 Feb 2004 18:44:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:76effd14-ed96-4c05-b840-33a51d6a162b</guid><dc:creator>Tony Zhou</dc:creator><description>&lt;p&gt;From your explanation, I&amp;#39;m quite clear on the problem now.&lt;br /&gt;
&lt;br /&gt;
Thank you very much.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/137807?ContentTypeID=1</link><pubDate>Mon, 09 Feb 2004 11:44:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ac5d6179-8270-4a79-9d14-f06dc1648b33</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;The actual problem is in the linker, then, and it&amp;#39;s for real.  I managed to reproduce it now.  The parameters:&lt;br /&gt;
&lt;br /&gt;
* C51 7.09 (--&amp;gt; everything current)&lt;br /&gt;
&lt;br /&gt;
* optimization &amp;gt;=2 (data overlaying) triggers it.&lt;br /&gt;
&lt;br /&gt;
According to the map file, the data sections for ExStamptoJDxTime() and DifferJDxTime() are indeed overlayed, so the objects&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;
?DifferJDxTime?BYTE
?ExStampToJDxTime?BYTE
&lt;/pre&gt;
&lt;br /&gt;
found in the posted *.lst excerpt end up both on the same address (032h at optimize 8).  This means the set-up of oExT2 as the argument to the conversion function overwrites the result of the previous call which had been copied into the space for the first argument of DifferJDxTime().&lt;br /&gt;
&lt;br /&gt;
Maybe the overlay generator just can&amp;#39;t cope with multi-byte return values that can&amp;#39;t be held in registers.&lt;br /&gt;
&lt;br /&gt;
Anyway: I conclude you&amp;#39;ll have to pass this over to Keil Support.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/129842?ContentTypeID=1</link><pubDate>Fri, 06 Feb 2004 20:03:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ffdf9866-edcc-495e-9821-705bacc8ca38</guid><dc:creator>Tony Zhou</dc:creator><description>&lt;p&gt;Sorry, Broeker. In last message, I missed a fragment. Here it is.&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;
0008         L?0020:
0008 7E00              MOV     R6,#00H
000A 7F08              MOV     R7,#08H
000C 120000      E     LCALL   ?C?COPY
             ; FUNCTION ExStampToJDxTime (BEGIN)
                                           ; SOURCE LINE # 134
                                           ; SOURCE LINE # 135
                                           ; SOURCE LINE # 138
000F E500        R     MOV     A,oExT1+02H
0011 2409              ADD     A,#09H
0013 75F00C            MOV     B,#0CH
0016 84                DIV     AB
0017 85F000      R     MOV     oExT1+02H,B
                                           ; SOURCE LINE # 141
001A AF00        R     MOV     R7,oExT1
001C 7E00              MOV     R6,#00H
001E 7C00              MOV     R4,#00H
0020 7D64              MOV     R5,#064H
0022 120000      E     LCALL   ?C?IMUL
0025 EF                MOV     A,R7
0026 2500        R     ADD     A,oExT1+01H
0028 F500        R     MOV     n_oJDxTime+05H,A
002A EC                MOV     A,R4
002B 3E                ADDC    A,R6
002C F500        R     MOV     n_oJDxTime+04H,A

......

                                           ; SOURCE LINE # 152
017E 7B00              MOV     R3,#00H
0180 7A00        R     MOV     R2,#HIGH n_oJDxTime
0182 7900        R     MOV     R1,#LOW n_oJDxTime
                                           ; SOURCE LINE # 153
0184         ?C0007:
0184 22                RET
             ; FUNCTION ExStampToJDxTime (END)

&lt;/pre&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/129843?ContentTypeID=1</link><pubDate>Fri, 06 Feb 2004 19:53:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2edee8af-1e0d-40cf-b9b2-20c5b29e19e7</guid><dc:creator>Tony Zhou</dc:creator><description>&lt;p&gt;Hi, Broeker. Thanks.&lt;br /&gt;
&lt;br /&gt;
On debugging, i met the problem in the implementation of function DifferExStamp(). The assembly code lines of function DifferDJxTime() seem good.&lt;br /&gt;
&lt;br /&gt;
The following are the relevant *.lst fragments.&lt;br /&gt;
&lt;br /&gt;
Best regards.&lt;br /&gt;
&lt;br /&gt;
&lt;pre&gt;
 155          CJDxTime DifferExStamp(CExStamp oExT1, CExStamp oExT2)
 156          {
 157   1              //===Data overlay improperly !!!
 158   1              return DifferJDxTime((ExStampToJDxTime(oExT1)),(ExStampToJDxTime(oExT2)));
 159   1      }
 160
 161          CJDxTime DifferJDxTime(CJDxTime oJDxT1, CJDxTime oJDxT2)
 162          {
 163   1              if (oJDxT1.dwX100ms &amp;lt; oJDxT2.dwX100ms)
 164   1              {
 165   2                      oJDxT1.lDays --;
 166   2                      oJDxT1.dwX100ms += (ULONG)SECONDS_PER_DAY*10L;
 167   2              }
 168   1
 169   1              oJDxT1.dwX100ms -= oJDxT2.dwX100ms ;
 170   1              oJDxT1.lDays -= oJDxT2.lDays ;

 171   1
 172   1              return oJDxT1;
 173   1      }
 174

             ; FUNCTION DifferExStamp (BEGIN)
                                           ; SOURCE LINE # 155
                                           ; SOURCE LINE # 156
                                           ; SOURCE LINE # 158
0000 7800        R     MOV     R0,#LOW ?ExStampToJDxTime?BYTE
0002 7C00        R     MOV     R4,#HIGH ?ExStampToJDxTime?BYTE
0004 7D00              MOV     R5,#00H
0006 7B00              MOV     R3,#00H
0008 7A00        R     MOV     R2,#HIGH oExT1
000A 7900        R     MOV     R1,#LOW oExT1
000C 120000      R     LCALL   L?0020
000F 7800        R     MOV     R0,#LOW ?DifferJDxTime?BYTE
0011 7C00        R     MOV     R4,#HIGH ?DifferJDxTime?BYTE
0013 7D00              MOV     R5,#00H
0015 7E00              MOV     R6,#00H
0017 7F08              MOV     R7,#08H
0019 120000      E     LCALL   ?C?COPY
001C 7800        R     MOV     R0,#LOW ?ExStampToJDxTime?BYTE
001E 7C00        R     MOV     R4,#HIGH ?ExStampToJDxTime?BYTE
0020 7D00              MOV     R5,#00H
0022 7B00              MOV     R3,#00H
0024 7A00        R     MOV     R2,#HIGH oExT2
0026 7900        R     MOV     R1,#LOW oExT2
0028 120000      R     LCALL   L?0020
002B 7800        R     MOV     R0,#LOW ?DifferJDxTime?BYTE+08H
002D 7C00        R     MOV     R4,#HIGH ?DifferJDxTime?BYTE+08H
002F 7D00              MOV     R5,#00H
0031 120000      R     LCALL   L?0023
                                           ; SOURCE LINE # 159
0034         ?C0008:
0034 22                RET

             ; FUNCTION DifferExStamp (END)

             ; FUNCTION L?0023 (BEGIN)
0000 7E00              MOV     R6,#00H
0002 7F08              MOV     R7,#08H
0004 120000      E     LCALL   ?C?COPY
             ; FUNCTION DifferJDxTime (BEGIN)
                                           ; SOURCE LINE # 161
                                           ; SOURCE LINE # 162
                                           ; SOURCE LINE # 163
0007 AF00        R     MOV     R7,oJDxT2+07H
0009 AE00        R     MOV     R6,oJDxT2+06H
000B AD00        R     MOV     R5,oJDxT2+05H
000D AC00        R     MOV     R4,oJDxT2+04H
000F AB00        R     MOV     R3,oJDxT1+07H
0011 AA00        R     MOV     R2,oJDxT1+06H
0013 A900        R     MOV     R1,oJDxT1+05H
0015 A800        R     MOV     R0,oJDxT1+04H
0017 C3                CLR     C
0018 120000      E     LCALL   ?C?ULCMP
001B 502E              JNC     ?C0009
                                           ; SOURCE LINE # 164
                                           ; SOURCE LINE # 165
001D 74FF              MOV     A,#0FFH
001F 2500        R     ADD     A,oJDxT1+03H
0021 F500        R     MOV     oJDxT1+03H,A
0023 E500        R     MOV     A,oJDxT1+02H
0025 34FF              ADDC    A,#0FFH
0027 F500        R     MOV     oJDxT1+02H,A
0029 E500        R     MOV     A,oJDxT1+01H
002B 34FF              ADDC    A,#0FFH
002D F500        R     MOV     oJDxT1+01H,A
002F E500        R     MOV     A,oJDxT1
0031 34FF              ADDC    A,#0FFH
0033 F500        R     MOV     oJDxT1,A
                                           ; SOURCE LINE # 166
0035 E4                CLR     A
0036 2500        R     ADD     A,oJDxT1+07H
0038 F500        R     MOV     oJDxT1+07H,A
003A E500        R     MOV     A,oJDxT1+06H
003C 342F              ADDC    A,#02FH
003E F500        R     MOV     oJDxT1+06H,A
0040 E500        R     MOV     A,oJDxT1+05H
0042 340D              ADDC    A,#0DH
0044 F500        R     MOV     oJDxT1+05H,A
0046 E4                CLR     A
0047 3500        R     ADDC    A,oJDxT1+04H
0049 F500        R     MOV     oJDxT1+04H,A
                                           ; SOURCE LINE # 167
004B         ?C0009:
                                           ; SOURCE LINE # 169
004B C3                CLR     C
004C E500        R     MOV     A,oJDxT1+07H
004E 9500        R     SUBB    A,oJDxT2+07H
0050 F500        R     MOV     oJDxT1+07H,A
0052 E500        R     MOV     A,oJDxT1+06H
0054 9500        R     SUBB    A,oJDxT2+06H
0056 F500        R     MOV     oJDxT1+06H,A
0058 E500        R     MOV     A,oJDxT1+05H
005A 9500        R     SUBB    A,oJDxT2+05H
005C F500        R     MOV     oJDxT1+05H,A
005E E500        R     MOV     A,oJDxT1+04H

0060 9500        R     SUBB    A,oJDxT2+04H
0062 F500        R     MOV     oJDxT1+04H,A
                                           ; SOURCE LINE # 170
0064 C3                CLR     C
0065 E500        R     MOV     A,oJDxT1+03H
0067 9500        R     SUBB    A,oJDxT2+03H
0069 F500        R     MOV     oJDxT1+03H,A
006B E500        R     MOV     A,oJDxT1+02H
006D 9500        R     SUBB    A,oJDxT2+02H
006F F500        R     MOV     oJDxT1+02H,A
0071 E500        R     MOV     A,oJDxT1+01H
0073 9500        R     SUBB    A,oJDxT2+01H
0075 F500        R     MOV     oJDxT1+01H,A
0077 E500        R     MOV     A,oJDxT1
0079 9500        R     SUBB    A,oJDxT2
007B F500        R     MOV     oJDxT1,A
                                           ; SOURCE LINE # 172
007D 7B00              MOV     R3,#00H
007F 7A00        R     MOV     R2,#HIGH oJDxT1
0081 7900        R     MOV     R1,#LOW oJDxT1
                                           ; SOURCE LINE # 173
0083         ?C0010:
0083 22                RET
             ; FUNCTION DifferJDxTime (END)
&lt;/pre&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/122294?ContentTypeID=1</link><pubDate>Fri, 06 Feb 2004 09:26:00 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3d2c0892-8574-45c5-bbdb-ff79ecd78c05</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;i&gt;The *.lst file is too long to post.&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
I didn&amp;#39;t ask for all of it --- just the relevant fragment, i.e. the implementation of function DifferExStamps(), should do.&lt;br /&gt;
&lt;br /&gt;
Actually, I did try to build your code, by the version of the compiler I have here (C51 7.06) actually refused to compile it, giving me an error C215: invalid cast.  I had to expand DifferExStamp() longhand (local variables for all intermediates and the return value), and then it seemed to work reasonably.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/122292?ContentTypeID=1</link><pubDate>Thu, 05 Feb 2004 23:43:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:abcd6384-eeeb-47be-8545-58da5c8b96a2</guid><dc:creator>Dan Henry</dc:creator><description>&lt;p&gt;I had said &lt;i&gt;&amp;quot;...if I recall correctly, casting like that on an lvalue is a no-no&amp;quot;&lt;/i&gt;.&lt;br /&gt;
&lt;br /&gt;
Then, Drew and Tony respectively replied &lt;i&gt;&amp;quot;The cast itself is legal...&amp;quot;&lt;/i&gt; and &lt;i&gt;&amp;quot;As for the casting and structur parameter passing, I consider it be legal&amp;quot;&lt;/i&gt;.&lt;br /&gt;
&lt;br /&gt;
Yes, it is legal.  Traveling in my way-back time machine, I now realize that what I had not recalled that introduced the no-no, was a more complex attempt at a pointer arithmetic operation on a casted pointer subexpression in part of a larger dereferencing expression appearing on the lefthand side of the assignment operator.&lt;br /&gt;
&lt;br /&gt;
So nevermind; my previous comment does not apply here for this simple cast.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/110738?ContentTypeID=1</link><pubDate>Thu, 05 Feb 2004 22:03:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3d263702-0207-4351-afa0-612df8726a6d</guid><dc:creator>Tony Zhou</dc:creator><description>&lt;p&gt;Hi, Broeker,Henry and Davis, Thank you.&lt;br /&gt;
&lt;br /&gt;
By taking your suggestion, i rewote the function DifferExStamp()and have worked round the problem.&lt;br /&gt;
&lt;br /&gt;
My opinion is that the problem is more likely a &amp;#39;compiler bug&amp;#39;. When i traced into disassembly code of DifferExStamp(), i found that the first parameter of DifferJDxTime(), which is the return value of the first ExStampToJDxTime() call, was overwritten by the second call to ExStampToJDxTime().&lt;br /&gt;
&lt;br /&gt;
As for the casting and structur parameter passing, I consider it be legal. No warning, no error is reported on compiling output.&lt;br /&gt;
&lt;br /&gt;
The *.lst file is too long to post. The posted source code is complete and can be built. Thanks for your further inspection.&lt;br /&gt;
&lt;br /&gt;
Best regards.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/96100?ContentTypeID=1</link><pubDate>Thu, 05 Feb 2004 12:18:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6f03635-9d7a-4912-b499-abeba825258e</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;The cast itself is legal, though it can be a bit risky on processors that are picky about their integer alignment.&lt;br /&gt;
&lt;br /&gt;
Perhaps more of a problem is that the cast turns a pointer into a signed 32-bit integer into a pointer to an unsigned 16-bit one.  Since Keil stores multi-byte integers MSB first, this code will be working on the high half of the long, which probably isn&amp;#39;t what is intended.&lt;br /&gt;
&lt;br /&gt;
I&amp;#39;m also dubious about the passing of entire structures as parameters and as return values.  But that&amp;#39;s more of an efficiency problem.&lt;br /&gt;
&lt;br /&gt;
The Hungarian notation makes my head hurt, so I can only stare at the code for a limited amount of time.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/86663?ContentTypeID=1</link><pubDate>Thu, 05 Feb 2004 07:43:34 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7c25eef9-f15d-4df2-993a-b1ca909fa98a</guid><dc:creator>Dan Henry</dc:creator><description>&lt;p&gt;&lt;i&gt;&amp;quot;But anyway: my prime suspect would be those pointer casting hacks in ExStampToJDxTime().&amp;quot;&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
Besides, if I recall correctly, casting like that on an lvalue is a no-no.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: C51 Compiler Bug, Help Please !</title><link>https://community.arm.com/thread/50230?ContentTypeID=1</link><pubDate>Thu, 05 Feb 2004 03:28:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a84caf78-f557-4e88-974b-c49b7fa8a910</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;You don&amp;#39;t show compiled code (i.e. *.lst file fragments) to back your claim, which makes this a bit harder than it strictly has to be.&lt;br /&gt;
&lt;br /&gt;
But anyway: my prime suspect would be those pointer casting hacks in ExStampToJDxTime().  They&amp;#39;re not just needlessly ugly, they may also have managed to confuse the call graph analysis done by Keil.  I suggest you get rid of them and try again.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>