<p dir="ltr">Well, FFI is what is used for quite a lot of wrappers.</p>
<p dir="ltr">And I haven&#39;t been using NB much even if I tried a thing or two.</p>
<p dir="ltr">What was interesting was Ronie&#39;s Swig project. Maybe the unified thing will be providing that capability too.</p>
<p dir="ltr">It is true that it is hard to figure out where things are going with all the new 64bit and ARM and stuff.</p>
<p dir="ltr">I have been collecting/reading/trying out things but it takes a motivated person to walk the path here.</p>
<p dir="ltr">Phil</p>
<div class="gmail_quote">Le 25 nov. 2014 19:37, &quot;Eliot Miranda&quot; &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt; a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 25, 2014 at 5:06 AM, Torsten Bergmann <span dir="ltr">&lt;<a href="mailto:astares@gmx.de" target="_blank">astares@gmx.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Please enlighten me as well. I also do not yet understand the idea of this unification layer.<br></blockquote><div><br></div><div>&quot;Unification layer&quot; is just a name.  IMO Ronie is doing something much more useful.  He is architecting the marshalling layer of the FFI so that it can </div><div>- be portable</div><div>- work in both the Cog JIT and the Interpreter</div><div>This is effectively an abstract instruction set for executing low-level machine intsructions.  It can be used for FFI call-out marshalling, but it can also be used for low-level code generation, and we are using it in Sista.  COnsequently Ronie&#39;s &quot;Low code&quot; as it is properly called can be an integral component to both a high-quality FFI and a fast VM.</div><div><br></div><div>For me this is a useful substrate for an FFI that can be high quality.  But note that it is only one component.  The other components are</div><div>- an image-level ABI compiler whose job it is to generate the correct marshalling code for different platforms.  The FFI for processors such as IA64/x86-64 is complex, and a compiler is the only performant way to generate correct marshalling code</div><div>- callback machinery.  I have already designed and implemented this in the context of Alien.  The architecture is portable; it can function correctly on x86-64 and ARM, not just x86.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
So far we have<br>
 1. FFI   -&gt; not maintained very well, no callbacks<br></blockquote><div><br></div><div>This is simply false.  The FFI was in active use at Qwaq where Cog was first implemented.  I have continued to maintain and enhance it, reimplementing it so that it is a pure Smalltalk plugin with no assembler support code, so that it is reentrant.  Recently Doug McPherson has implemented the ARM version alongside my original x86 version.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 2. Alien -&gt; should provide the callbacks, hard to find a predefined package/VM combination<br></blockquote><div><br></div><div>Every Cog VM supports Alien callbacks.  The Alien package Alien-eem.24 at <a href="http://www.squeaksource.com/Alien" target="_blank">http://www.squeaksource.com/Alien</a> &quot;jsut works&quot;, at least in Squeak.  Try it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2.<br></blockquote><div><br></div><div>I disagree.  NativeBoost has not been designed with portability in mind, nor has it been designed with interpretive VMs in mind.  Further Igor made no attempt to work with me in providing the support he needs from Cog to integrate NativeBoost when I visited Rmod early this year.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">According to my knowledge it was the goal to continue with NB, integrate it (which is done)<br>
and move it forward as the single solution for external calls and callbacks.<br>
<br>
So why do we need another layer (and mixed approach with still old FFI) instead of working<br>
on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn&#39;t there<br>
already work for AsmJit for ARM?<br></blockquote><div><br></div><div>We have a functional FFI at the moment, FFI + Alien for callbacks.  This is in industrial use, both at Terf (nee Qwaq) and Cadence.  We have NativeBoost that does not work on ARM.  We have Ronie&#39;s work on low code that fits both with a well-architected FFI and with Sista.</div><div><br></div><div>I am frustrated that there is no coherence in our work here.  I have a clear understanding of what architecture can work, a clear vision, and yet other than Ronie, all I see is FUD (&quot;Alien doesn&#39;t work&quot;, &quot;FFI doesn&#39;t work&quot;, &quot;Alien callbacks don&#39;t work&quot;; all false).  I wish this wasn&#39;t the case.  I do not have time right now to work on all of Spur, Spur 64, Sista and find time to architect the FFI.  But I know how this stuff works (I&#39;ve implemented what works now) and as the leads VM architect isn&#39;t it right that the community try and work with me rather than without me?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thx<br>
T.<br>
<br>
&gt; Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr<br>
&gt; Von: &quot;Markus Fritsche&quot; &lt;<a href="mailto:mfritsche@reauktion.de" target="_blank">mfritsche@reauktion.de</a>&gt;<br>
&gt; An: &quot;Pharo Development List&quot; &lt;<a href="mailto:pharo-dev@lists.pharo.org" target="_blank">pharo-dev@lists.pharo.org</a>&gt;<br>
&gt; Betreff: Re: [Pharo-dev] NativeBoost<br>
<div><div>&gt;<br>
&gt; On 2014-11-24 23:34, Esteban Lorenzano wrote:<br>
&gt;<br>
&gt; &gt; now, since the most common use of NB is for FFI, and NB is not present<br>
&gt; &gt; in all platforms, we are working (Ronie, in this case) in a “unified<br>
&gt; &gt; FFI”, which will provide a common abstraction layer for several FFI<br>
&gt; &gt; frameworks (NB, OldFFI, Alien…). With that, we can choose which one<br>
&gt; &gt; of the frameworks we use depending on the situation (but ideally, we<br>
&gt; &gt; will maintain just one, the one that fits better in Pharo).<br>
&gt;<br>
&gt; I feel that providing a common abstraction layer on top of the various<br>
&gt; approaches to interface to C/ C++ libraries won&#39;t be useful and should<br>
&gt; be considered a waste of resources. From what I understood from the<br>
&gt; documentation, NativeBoost seems to be the most complete interface<br>
&gt; technology yet. I would rather (as in: If I was capable) try to get<br>
&gt; NativeBoost into Squeak and add the functionality missing that still<br>
&gt; justifies the existence of FFI and Alien than creating an abstraction<br>
&gt; layer that can&#39;t cope with the differences in the tools (which was the<br>
&gt; reason for their first creation despite the available ones).<br>
&gt;<br>
&gt; I tried to play around with FFI and creating plugins in Squeak and<br>
&gt; failed (I didn&#39;t try very hard though). NativeBoost was the first thing<br>
&gt; I was able to wrap a DLL myself and understand how to do it. The only<br>
&gt; thing that I wasn&#39;t able to wrap my mind around was finalization, but<br>
&gt; that is also due to the fact that I couldn&#39;t find understandable (read:<br>
&gt; understandable to me) documentation about the underlying concept in<br>
&gt; Pharo.<br>
&gt;<br>
&gt; (OT: Finalization and concurrency probably is more about the concept<br>
&gt; rather than the implementation in Pharo?)<br>
&gt;<br>
&gt; This is a piece of opinion. We all know, that unfortunately, one doesn&#39;t<br>
&gt; have to have knowledge to have an opinion, so if my opinion is wrong due<br>
&gt; to lack of knowledge, please ignore it.<br>
&gt;<br>
&gt; Best regards,<br>
&gt;    Markus<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>best,<div>Eliot</div></div>
</div></div>
</blockquote></div>