Re: Rust vs. C backend
I have run Daffodil using Graal VM for Java 21. It's slower than regular Java 21. Not massively, but enough that I set it aside immediately. Don't ask me the tests I ran tho. I can't recall. This was about a year ago. I looked into Scala Native a short time back. I was unable to get it to work for my little lbsfdump program mentioned below. Selective linking with Graal VM i.e., the scala nativeImage plugin (not to be confused with the scala-native plugin) was somewhat effective. See: https://github.com/apache/daffodil-extra/tree/main/lsbfdump which is a little dump utility I (and ChatGPT) created in scala 2.13 which uses graal-vm and compiles to a fairly small executable: 12Mbytes or so. On Tue, Jan 16, 2024 at 7:12 PM Adam Rosien wrote: > I'm curious if a non-source-generated solution would work, specifically > Scala Native and Graal? That is, there are non-JVM targets that can be > built from the Scala source, and they can be extremely performant. The > current hotness is the "billion row challenge" ( > https://github.com/gunnarmorling/1brc) where Graal-based solutions are > hands-down the winners. > > On Thu, Jan 11, 2024 at 2: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 > > Sent: Thursday, January 11, 2024 5:13 AM > > To: John Interrante > > 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/> > > >
Re: Rust vs. C backend
I'm curious if a non-source-generated solution would work, specifically Scala Native and Graal? That is, there are non-JVM targets that can be built from the Scala source, and they can be extremely performant. The current hotness is the "billion row challenge" ( https://github.com/gunnarmorling/1brc) where Graal-based solutions are hands-down the winners. On Thu, Jan 11, 2024 at 2: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 > Sent: Thursday, January 11, 2024 5:13 AM > To: John Interrante > 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/> >
Re: Rust vs. C backend
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 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 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 > > > 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 > > >
Re: Rust vs. C backend
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 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 > > 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 > > > Sent: Thursday, January 11, 2024 5:13 AM > > > To: John Interrante > > > 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 a
Rust vs. C backend
Mike, I googled "calling rust from java" since Scala is similar to Java. I have only very limited experience with calling native code from Java programs, but I believe the following apply: 1) you have to do some painstaking and careful programming to make the Java Native Interface code and the Rust code compatible so the calls can go through; 2) the performance hit doesn't slow down the calls very much. Someone wrote up a success story called "Using Rust in-process with Java" here: https://www.vortexa.com/insights/technology/rust-in-process-java/ Someone wrote a library called j4rs to help call Java from Rust and the library also supports the reverse direction from Java to Rust: https://github.com/astonbitecode/j4rs-java-call-rust https://lib.rs/crates/j4rs Incrementally rewriting part of Daffodil in Rust to speed up Daffodil is a more holistic approach than translating a DFDL schema to Rust code to parse and unparse data. A code generator backend supports only a subset of the DFDL specification because it takes a lot of time and work to support the entire specification, while Daffodil can benefit from a speedup on most platforms (except platforms where a Rust compiler isn't available) while continuing to support all DFDL schemas. John -Original Message- From: Mike Beckerle Sent: Tuesday, January 16, 2024 5:43 AM To: dev@daffodil.apache.org Subject: EXT: Re: Rust vs. C backend 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 > 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 fo
Re: Rust vs. C backend
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 > 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 > > Sent: Thursday, January 11, 2024 5:13 AM > > To: John Interrante > > 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/> > > >
Rust vs. C backend
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 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 > Sent: Thursday, January 11, 2024 5:13 AM > To: John Interrante > 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/> >
Re: Rust vs. C backend
re: 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 > Sent: Thursday, January 11, 2024 5:13 AM > To: John Interrante > 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/> >
RE: Rust vs. C backend
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 Sent: Thursday, January 11, 2024 5:13 AM To: John Interrante 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/>
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 OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com
