We have some experience with jnr-ffi: daffodil-vscode uses omega-edit via jnr-ffi bindings for the extension's data editor. See https://github.com/ctc-oss/omega-edit/blob/4965d83ae40284ec8cf7af71d7c692060dbd21fb/server/scala/api/src/main/scala/com/ctc/omega_edit/FFI.scala#L262 for the binding of the native lib into Scala.
On Tue, Jan 16, 2024 at 3:42 PM John Wass <jwa...@gmail.com> wrote: > Hi Mike- > > Take a look at > > https://github.com/jni-rs/jni-rs > > There is a good example in the repo. > > I'd compare that against jnr-ffi, which is nice in general for jni work. > > https://github.com/jnr/jnr-ffi > > -john > > > On Tue, Jan 16, 2024, 08:42 Mike Beckerle <mbecke...@apache.org> wrote: > > > John, what do you (or anyone?) know about interfacing Rust and JVM > > languages like Java/Scala? A quick search pulled back nothing other than > > Java JNI and/or sending GPBs back and forth to micro-services. > > > > I'm wondering if incrementally rewriting parts of the existing, slow, > Scala > > backend in Rust is feasible, or if this is not a smooth enough pathway. > > > > For example, I suspect that Daffodil's lexical analyzer could use a > > rewrite. It is one of the oldest pieces of code in Daffodil, and was > > created back when myself and others were really still Scala newbies, and > we > > were just learning the implications for the lexical analyzer design I.e., > > discovering them the hard way, realizing the design was not sufficiently > > general, adding more tweaks (which could be suboptimal), etc. We had not > > yet developed the philosophy that the backend code should be "java like", > > and not use scala idioms that are less efficient. > > > > But if we're rewriting parts of the back-end and the rewrites are > intended > > to be high performance, then it would seem the right language to use is > > something like Rust. > > > > However, this requires that we're able to call it efficiently and that > the > > bridge from scala to that rust code is not so expensive as to eliminate > the > > performance gain. > > > > > > > > On Fri, Jan 12, 2024, 5:52 PM Interrante, John A (GE Aerospace, US) < > > john.interra...@ge.com> wrote: > > > > > We developed a fork of the C backend that generated VHDL, but I can't > get > > > into the implementation details here. I think the line between Rust > and > > C > > > is two-fold: how many machine architectures Rust has been ported to, > and > > > how often you need to call C functions from Rust, which means having to > > use > > > Rust's Foreign Function Interface. Otherwise, Rust is better than C > for > > > new code and Daffodil should have a Rust backend. > > > > > > -----Original Message----- > > > From: Mike Beckerle <mbecke...@apache.org> > > > Sent: Friday, January 12, 2024 5:50 AM > > > To: dev@daffodil.apache.org > > > Subject: EXT: Re: Rust vs. C backend > > > > > > what I meant by "What did you mean by the phrase “basis for generating > > > VHDL or System Verilog?” > > > > > > I suppose I was thinking you had a fork of the C backend that created > > > Verilog/VHDL, but perhaps the pathway is via the C code output, which > is > > > then translated into Verilog/VHDL? > > > > > > In any case we're hearing lots more complaints about performance of > > > Daffodil's scala back-end (and missing optimizations in the middle > > phases). > > > > > > Generating C code won't work for Cyberian software-based applications > as > > a > > > memory-safe language is required in these solutions. I will have to > learn > > > more about Rust. We need a memory safe language that lets you control > the > > > data representations far better than Java/Scala and JVM languages. I am > > > curious where the line is between Rust and C, i.e., what kinds of > things > > > are possible in C that aren't possible in Rust. > > > > > > On Thu, Jan 11, 2024 at 5:01 PM Interrante, John A (GE Aerospace, US) < > > > john.interra...@ge.com> wrote: > > > > > > > Hi Mike, > > > > > > > > My view is that when the goal is to generate parsers and unparsers > > > > from fixed format binary data DFDL schemas, compile them to native > > > > machine code, and execute the machine code on CPUs, Daffodil should > > > > generate Rust. We would have preferred Rust when we started the C > > > > code generator work. Rust is memory safe, type safe, etc. – but it > > > > was not available for our phase 1 target CPU. > > > > > > > > Creating a Rust backend makes sense, although we don’t think there is > > > > a Rust to hardware path – at least none that we are aware of. What > > > > did you mean by the phrase “basis for generating VHDL or System > > Verilog?” > > > > > > > > John > > > > > > > > From: Mike Beckerle <mbecke...@apache.org> > > > > Sent: Thursday, January 11, 2024 5:13 AM > > > > To: John Interrante <jinterra...@apache.org> > > > > Cc: dev@daffodil.apache.org > > > > Subject: EXT: Rust vs. C backend > > > > > > > > John, > > > > > > > > What's your view of generating Rust vs. Generating C from DFDL? > > > > > > > > Those of us working in Cyberia, well, the edict has been issued that > > > > only memory-safe languages/runtimes are allowed to reduce risk of > > > > cyber-attacks via things like libc flaws. > > > > > > > > Seems to me that Rust is the lowest level language that would be > > > > acceptable > > > > > > > > I believe ultimately, the goal is to generate a useful software > > > > implementation that does not compromise on performance, and to be a > > > > basis for generating VHDL or System Verilog. > > > > > > > > I imagine you've given this some thought you can share. > > > > Mike Beckerle > > > > Apache Daffodil PMC | daffodil.apache.org< > http://daffodil.apache.org/> > > > > OGF DFDL Workgroup Co-Chair | > > > > www.ogf.org/ogf/doku.php/standards/dfdl/dfdl > > > > <http://www.ogf.org/ogf/doku.php/standards/dfdl/dfdl> > > > > Owl Cyber Defense | www.owlcyberdefense.com< > > > > http://www.owlcyberdefense.com/> > > > > > > > > > >
