<div><caret></caret>On Mon, May 25, 2020 at 12:46, tim Rowledge <<a href="mailto:tim@rowledge.org" class="">tim@rowledge.org</a>> wrote:<br></div><blockquote class="protonmail_quote" type="cite">  <br>OK, I'll try to answer some of the thoughts on this -<br><br>> On 2020-05-24, at 11:07 PM, Robert <robert.withers@pm.me> wrote:<br>><br>> How about the CryptographyPlugins? What would switching to FFI look like? I feel like we still need custom C code implementing the algorithms.<br>><br>> Is it that we would have shared object libraries (.so/DLLs), generated from slang, but not creating plugins, just generating .so libs and the FFI calls to use them?<br><br>Right now (assuming I'm remembering it all correctly and with the proviso that I haven't written a new plugin in several years) an external plugin is compiled from the assorted code required (some plugins are solely slang generated code, some are solely hand-written C, some are slang + C + calls to other libraries and so on) and a platform specific form of shared library is made. Are they in a form that is callable via 'normal' ffi calls? Dunno, but clearly they *could* be made that way with not very much change.</blockquote>Tim, does this mean that the plugin generation and linking as appropriate continues a pace, while the in-image named prims table switches all entries to FFI calls? CryptographyPlugins have the advantage of slang generated only code.<div><br></div><div>Would it be possible to take advantage of a GPU??</div><div><br></div><div>K, r<caret></caret><br><div><br></div></div>