<?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>function pointers in Dallas 390 contiguous mode</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/19690/function-pointers-in-dallas-390-contiguous-mode</link><description> I was struggling with the function pointer in Dallas 390 contiguous mode. It seems that the linker might not relocate the correct address in function pointer. Check the following code: 
 

void Test(void)
{
 UINT32 u32Tmp;

 u32Tmp = 0x12345678ul;
 TASK_PRN</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: function pointers in Dallas 390 contiguous mode</title><link>https://community.arm.com/thread/87652?ContentTypeID=1</link><pubDate>Mon, 27 Mar 2006 01:38:22 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b03d2618-12f1-448c-816d-0bb539608734</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;i&gt;Linker Bug confirmed&lt;/i&gt;&lt;br /&gt;
&lt;br /&gt;
No. You need to read the section in the Cx51 Compiler User&amp;#39;s Guide about Language Extensions-&amp;gt;Memory Types-&amp;gt;Far. It contains the description of how &amp;quot;far&amp;quot; memory pointers are mapped on Dallas devices.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: function pointers in Dallas 390 contiguous mode</title><link>https://community.arm.com/thread/45776?ContentTypeID=1</link><pubDate>Fri, 24 Mar 2006 11:51:01 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6d372dd4-6f2b-4776-8a95-379cbdef5b2a</guid><dc:creator>Jon Ward</dc:creator><description>&lt;p&gt;&lt;p&gt;
Refer to the following KB article: &lt;a href="http://www.keil.com/support/docs/2226.htm"&gt;http://www.keil.com/support/docs/2226.htm&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
And to the description for far pointers in the C51 Manual:
&lt;a href="http://www.keil.com/support/man/docs/c51/c51_le_far.htm"&gt;http://www.keil.com/support/man/docs/c51/c51_le_far.htm&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Based on this information and the address of your function
(2D90EH), I would conclude that the far pointer to the function
should contain 0x83D90E.&lt;/p&gt;

&lt;p&gt;
Jon&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: function pointers in Dallas 390 contiguous mode</title><link>https://community.arm.com/thread/45775?ContentTypeID=1</link><pubDate>Fri, 24 Mar 2006 11:13:34 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:24cc52e8-25ce-41de-9f4c-d24aaa2742d0</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;The bug is in your expectations, not in the linker.  What on earth made you assume you knew what the result of casting a pointer to an integer was, better than the tools that actually use those pointers?  Do you know what terms like &amp;quot;undefined behaviour&amp;quot; or &amp;quot;unspecified result&amp;quot; mean?&lt;br /&gt;
&lt;br /&gt;
Not only is your expectation unfounded, it actually contradicts the documented behaviour, too.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: function pointers in Dallas 390 contiguous mode</title><link>https://community.arm.com/thread/87653?ContentTypeID=1</link><pubDate>Fri, 24 Mar 2006 04:05:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c822aabd-ade4-446d-b271-a355e85f0136</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;Be sure to also report this direct to Keil support!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: function pointers in Dallas 390 contiguous mode</title><link>https://community.arm.com/thread/45782?ContentTypeID=1</link><pubDate>Fri, 24 Mar 2006 02:35:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c3e14c36-d4f9-45ab-8079-de878f12c119</guid><dc:creator>Lucas  Lin</dc:creator><description>&lt;p&gt;&lt;b&gt; Linker Bug confirmed &lt;/b&gt;&lt;br /&gt;
I&amp;#39;ve checked the assembly listing and the generated binary code. And I found that the linker does not give correct relocation address in instruction relocation record.&lt;br /&gt;
&lt;b&gt; assembly listing &lt;/b&gt;&lt;br /&gt;
&lt;pre&gt;
             ; FUNCTION Test (BEGIN)
; SOURCE LINE # 246
; SOURCE LINE # 247
; SOURCE LINE # 250
0000 7F78              MOV     R7,#078H
0002 7E56              MOV     R6,#056H
0004 7D34              MOV     R5,#034H
0006 7C12              MOV     R4,#012H
;---- Variable &amp;#39;u32Tmp&amp;#39; assigned to Register &amp;#39;R4/R5/R6/R7&amp;#39; ----
; SOURCE LINE # 251
0008 7B00        R     MOV     R3,#MBYTE ?SC_117
000A 7A00        R     MOV     R2,#HIGH ?SC_117
000C 7900        R     MOV     R1,#LOW ?SC_117
000E 90000000    E     MOV     DPTR,#?UART_iPrintk?BYTE
0012 12000000    E     LCALL   ?C?PSTXDATA
0016 90000000    E     MOV     DPTR,#?UART_iPrintk?BYTE+03H
001A 12000000    E     LCALL   ?C?LSTXDATA
001E 12000000    E     LCALL   UART_iPrintk
                                           ; SOURCE LINE # 252
0022 7B00        R     MOV     R3,#MBYTE Test
0024 7A00        R     MOV     R2,#HIGH Test
0026 7900        R     MOV     R1,#LOW Test
0028 AF01              MOV     R7,AR1
002A AE02              MOV     R6,AR2
002C AD03              MOV     R5,AR3
002E 7C00              MOV     R4,#00H
&lt;/pre&gt;
&lt;b&gt; Binary Code &lt;/b&gt;&lt;br /&gt;
&lt;pre&gt;
1D90E: 7F 78       ; MOV R7 , #078H
1D910: 7E 56       ; MOV R6, #056H
....
1D930: 7B 83       ; MOV R3, #083H
1D932: 7A D9       ; MOV R2, #0D9H
1D934: 79 0E       ; MOV R1, #00EH
&lt;/pre&gt;
&lt;br /&gt;
That&amp;#39;s why I get the strange results:&lt;br /&gt;
&lt;pre&gt;
32Func = 12345678
u32Func = 83d90e
&lt;/pre&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>