Steve Lawrence and I would like to bring another topic from my runtime2 pull
request to the dev list for wider discussion. The question is how would you
expect to use and trigger different Daffodil backends? We believe these
requirements hold:
- Daffodil's Scala runtime/backend/whatchacallit will support the entire
DFDL 1.0 specification
- A new Daffodil backend will generate C code for a minimally viable subset
of the DFDL 1.0 specification for small footprint devices
- Daffodil will support running TDML tests against both backends (C code
generation, C code compilation, and invoking of compiled code all transparent
to the user)
- Daffodil may add more backends in the future (maybe runtime3 might
generate VHDL files for chips)
In addition, the following requirements may hold too:
- We may want to use the same TDML "snap compilation/execution" mechanism
to have "daffodil parse" and "daffodil unparse" CLI commands that work alike
across the backends, but a counter argument is that there's little benefit to
be gained when the C code could be executed directly using its own similar
"daffodil parse" and "daffodil unparse" CLI syntax, and a VHDL simulator is
needed to "snap compile/execute" VHDL files anyway.
- The C generator should generate an ".a" or ".so" C-callable library and
matching ".h" include files that implement C APIs for parsing and unparsing
binary data corresponding to the given DFDL schema. This generated code
library would be distinct from the C runtime2 library which contains common
low-level parsing/unparsing functions implemented in C. Actually, all
generated and runtime2 ".c" source files should be written to an output
directory in case both libraries have to be compiled on another platform.
Creating the generated library feels like what the CLI should do when using the
runtime2 backend. There is an analogy here to what invoking the "daffodil
save-parser" subcommand does (it creates a saved parser file which speeds up a
future parse). Likewise, it makes sense to generate & compile the C code
first, then run the C-code executable directly using its own "daffodil parse"
and "daffodil unparse" CLI syntax. Or generate the VHDL files first and then
load them into a VHDL simulator.
Steve, Mike, and I have discussed different CLI commands for creating the
generated library:
daffodil runtime2 -s schema.dfdl.xsd -o schema.bin
daffodil save-parser -s schema.dfdl.xsd -Truntime=runtime2 outfile
daffodil generate C -s schema.dfdl.xsd outdir/
Each has pros and cons. Using "daffodil <runtime>" means each runtime/backend
can use its own CLI options more easily. The outfile passed to "daffodil
save-parser" is a filename but the C generator needs a directory name since it
has to write multiple files into it. We can run different backends with
"daffodil generate C" or "daffodil generate VHDL" and if different backends
need different CLI options maybe the Daffodil Scala CLI can ask the different
backends for their CLI options.
What do devs think? Keep the Daffodil Scala CLI focused on Daffodil's Scala
runtime and make new runtimes use a separate CLI tool with a unique name and
its unique CLI syntax? Or shoehorn some additional functionality into the
Daffodil Scala CLI syntax?
