<whitequark[cis]>
<Wanda[cis]> "there's also the whole yosys-..." <- there is also the fact that using the same netlist representation throughout the entire flow makes debugging and interoperation a lot nicer
<jn>
one usecase i'm dreaming of (although it's probably possible with icestorm+yosys+symbiyosys): lifting a bitstream into netlist form, refactoring it under formally proven equivalence until it makes sense and looks nice
<Wanda[cis]>
heh
<Wanda[cis]>
that's ... pretty far from what we're envisioning for prjunnamed
<Wanda[cis]>
it's also hm
<Wanda[cis]>
not quite as impossibly complex as making a good decompiler, but many of the same considerations apply
<Wanda[cis]>
funnily enough, we had an interesting conversation with Cat recently about the relative amount of work needed to make a good FPGA toolchain and a good interactive disassembler / decompiler (these are both the kinds of projects I'm very interested in working on); Cat's thesis is that the disassembler is infinitely more complex because of all the requirements of interactivity and letting you essentially manipulate compiler data structures
<Wanda[cis]>
in real time, and thus we actually have a chance of making a reasonably good FPGA toolchain, but not of making a reasonably good disassembler
<jn>
yes
<jn>
i suppose a solid base of transformable IR helps towards both project goals
<Wanda[cis]>
depends
<Wanda[cis]>
I mean, yes
<Wanda[cis]>
but
<Wanda[cis]>
the prjunnamed IR, or more specifically its in-memory data structures, are designed for a classic batch compiler
<Wanda[cis]>
I'm not convinced they'd be a good fit for something interactive
<Wanda[cis]>
or, for that matter, for an incremental compiler
<Wanda[cis]>
however, you could conceivably reuse the same "instruction set" on top of data structures designed with interactive operation in mind
RobTaylor[m] has joined #prjunnamed
<RobTaylor[m]>
<jn> "one usecase i'm dreaming of (..." <- maybe worth looking at the naja project