<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Fair enough.  What about calling functions like Int via assembly language, since it's currently impossible to do it either via the internal function or using the public symbol that maps to it, since <span class="swb">"CALL int" just raises a linker error - I presume it's not as easy as copying some code from procedure-calling node generation:<br>
 
<br>
 
"Error: Undefined symbol: SYSTEM_::=::\_INT$DOUBLE::=::\DOUBLE"</span></div><br>
Gareth aka. Kit<br>
 <br>
<br>
<span style="font-weight: bold;">On Sun 03/02/19 11:17 , Jonas Maebe jonas@freepascal.org sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">On 03/02/19 05:08, J. Gareth Moreton wrote:
<br>


<br>

<span style="color: rgb(102, 102, 102);">> Basically, if you declare a public symbol (either using the "public" 
</span><br>

<span style="color: rgb(102, 102, 102);">> directive or putting it in the interface section of a unit) with a name 
</span><br>

<span style="color: rgb(102, 102, 102);">> that's identical to an internal symbol (I used "FPC_ABSMASK_DOUBLE"), 
</span><br>

<span style="color: rgb(102, 102, 102);">> you get a 'duplicate symbol' linker error... in fact, Lazarus doesn't 
</span><br>

<span style="color: rgb(102, 102, 102);">> even display the error (see bug #34996) - it only appears if you run the 
</span><br>

<span style="color: rgb(102, 102, 102);">> compiler from the command line.
</span><br>


<br>

The FPC (and _FPC) namespace is reserved for internal use. Detecting 
<br>

such clashes is not possible without adding all declared external 
<br>

symbols to hash tables, which would reduce both compilation speed and 
<br>

increase memory usage. I think it's better to simply document that such 
<br>

symbols are reserved for compiler and RTL usage.
<br>


<br>

<span style="color: rgb(102, 102, 102);">> You can get around the above issue if you simply rename the constant or 
</span><br>

<span style="color: rgb(102, 102, 102);">> keep it private.  However, there is one other issue that is not so easy 
</span><br>

<span style="color: rgb(102, 102, 102);">> to circumvent, and that's when you try to call an internal function 
</span><br>

<span style="color: rgb(102, 102, 102);">> through assembly language (in this instance, I'm assuming the code is 
</span><br>

<span style="color: rgb(102, 102, 102);">> not cross-platform and I'll be calling the x86_64 version of 
</span><br>

<span style="color: rgb(102, 102, 102);">> fpc_int_real, which is "nostackframe" and only modifies XMM0 and RAX):
</span><br>


<br>

Calling internal functions directly is unsupported, which is the reason 
<br>

why they are made inaccessible from regular code. Their signature or 
<br>

behaviour can change across compiler versions (or they may even 
<br>

disappear altogether). You can hack around it by declaring external 
<br>

functions mapping to the symbol name of the internal function, but 
<br>

again, that is completely unsupported.
<br>


<br>


<br>

Jonas
<br>

_______________________________________________
<br>

fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<br>

<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a>
<br>

<br>

<br>

</blockquote></HTML>