<div class="gmail_quote">2009/8/27 David Schleef <span dir="ltr">&lt;<a href="mailto:ds@entropywave.com">ds@entropywave.com</a>&gt;</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is exactly the case where the liboil model breaks down.  If<br>
you have one public symbol for a function that might be used by<br>
multiple modules in a complex application, the modules would<br>
potentially fight over which approximation to use.<br>
<br>
Also, in my observation, changing the underlying approximation for<br>
an algorithm changes more than just the implemenation of the<br>
liboil-like functions that would be used: it potentially changes<br>
the optimal memory layout, function prototypes, iterators, etc.<br>
<br>
For example, the idct8x8_s16 and idct8x8lim10_s16 classes in<br>
liboil do the same operation, but the latter limits the calculation<br>
to the lowest 10 coefficients of the 8x8 DCT block, assuming the<br>
rest of the coefficients are zero.  If these were merged into the<br>
same symbol, the calling code would have to always zero the upper<br>
54 coefficients in case the non-approximated code was called (say<br>
for testing, or for the case where another module overwrote the<br>
preferred implementation.)  This negates much of the reason for<br>
using the approximation in the first place.<br>
<div class="im"></div></blockquote><div><br></div><div>I agree in this case. </div><div><br></div><div>Generally, we need the the model of &quot;one public function symbol, multiple implements&quot;, because we can&#39;t decide which implement is suitable at *the time*.</div>
<div><br></div><div>liboil can&#39;t decide which implements are suitable at build time, so it builds a series of of implements at build time and activates some at runtime.</div><div><br></div><div>Orc builds implements at runtime, it can know which implements are suitable at this stage.</div>
<div><br></div><div>But doing too many things at runtime, as I wrote,  will a) either pull too many dependencies. b) or have some duplicate code to implement some features(e.g. OilString in liboil and GString in glib)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
&gt; 3) How to generate code in runtime? fork a process and exec &quot;as&quot;?<br>
<br>
</div>The source code is not hidden.  Short answer is &quot;no&quot;.<br>
<br>
</blockquote><div>It seems binutils doesn&#39;t export C-APIs, so native code generation will a) fork a process and execute &quot;as&quot; or b) <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">generate</span> machine code directly.</div>
<div><br></div><div>Orc takes the second way, it may need to maintain a map of assembly to native code ?</div><div><br></div><div>Regards,</div><div>cee1</div></div><br>