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/> > > > > > >
