<html>
<head>
<meta http-equiv="content-type" content: text/html; charset=utf-8>
</head>
<body>
<span style="color: gray;">04/13/17 23:50:35, (Marco van de Voort) <<a
href="mailto:marcov@stack.nl">marcov@stack.nl</a>>:</span><br>
Thanks, i understand all of this. This what i call plugin system and i know
for what it need. <span class="ref_result">In conclusion</span><em
class="trsc"></em>:<br>
Dynamic Packages needs for smooth plugin system in FreePascal.<br>
<br>
<span style="color: gray;">04/13/17 23:27:06, Sven Barth via fpc-devel
<<a
href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>>:</span><br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">No, those changes are not optional, though in
those cases where the<br>
compiler can avoid them (e.g. inside the same unit) it already tries
to.<br>
</blockquote>This why i start this discussion. Because i think this is bad
and i hope than this can be avoided.<br>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">And for global variables you can use
{$importdata off}.<br>
</blockquote>Compiler says that "Warning: Illegal compiler directive
"$IMPORTDATA"". How to use it?<br>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">Please not that our threadvars are *not*
allocated by the linker. Each<br>
access to a threadvar goes through the fpc_relocate_threadvar function<br>
(just check the assembler code to see what I mean)<br>
</blockquote>I know it. I say about action before calling
fpc_relocate_threadvar.<br>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">Delphi uses these indirect accesses from the
beginning. Do you hear<br>
anyone really complain about performance problems due to indirect
accesses?<br>
</blockquote>I even dont know about Delphi have it. I just use logic and my
<span class="ref_result">knowledge</span><em class="trsc"></em> about how
processor and memory works. So i try make my code faster.<br>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">And it's not about saving RAM or disk memory!
It's about *binary code<br>
reuse*, the ability to fix a bug in multiple executables by merely<br>
fixing the one bug in a package.<br>
</blockquote>Hm... Ok, i dont think that this in usefull at all, but
thanks, not i know your vision of problem.<br>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">These special sections are executed by the C
runtime. <br>
</blockquote>Interesting. I think its done by OS-part (on Windows, where i
see it).<br>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">We don't link against the C runtime at least
on Windows and on Linux however which<br>
reduces the dependencies.<br>
</blockquote>On Windows we in anycase have ntdll.dll and kernel32.dll, i
mean rel on their functional and think than this sections processed by
them. On Linux, if you use any SO - you use libdl, that use libc. In 99% of
programs we have it linked.<br>
<br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204);margin: 0 0 0
0.8ex;padding: 1ex 0 0 1ex;">No. This will needlessly complicate
things.<br>
</blockquote>Ok. I understand. I make proposal, you rejected it. Thanks for
you, and all other guys, that spent their time for this discussion.<br>
<br>
Regards,<br>
Roman<br>
<br>
</body>
</html>