<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 29, 2014 at 5:33 AM, Jean-Claude Beaudoin <span dir="ltr"><<a href="mailto:jean.claude.beaudoin@gmail.com" target="_blank">jean.claude.beaudoin@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I have looked at it more than once along the years and I don't like the bloat it has come to be.<br></div><div>So it is not much to my taste. And I expect it will be a major PITA when time comes to push the<br>

</div><div>performance of the FFI as much as I want to do it. Also, I am currently reworking the FFI entirely<br></div><div>anyway. I am not against learning from it though.<br><br><br></div></div></div></div></blockquote>
<div><br></div><div>I forgot to mention two things. First, the FFI is needed in anything more than a stub form only if one intends to specifically use its very services.  It used to be an optional part in ancient times under the name of "dynamic FFI" and MKCL can be still be a pretty useful piece without it. It just cannot then call foreign code from the bytecode interpreter, which is not much of a real drag in most situations.<br>
<br></div><div>Second, I am expecting the ARM to be the last architecture with assembler support in MKCL. I am of the opinion that nothing of interest will come up in that department for decades to come, but that is just my opinion. Although that opinion is not out of a lack of knowledge in that area since I have done significant coding in about 10 different assemblers along the years. And I am ready to bet pretty heavily on my position here.<br>
<br><br><br><br></div></div></div></div>