[libre-riscv-dev] nmigen frustrations make me want Rust

[Jacob Lifshay]

On Sun, Mar 17, 2019, 15:54 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Monday, March 18, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> > One additional option is to add nmigen interop support to the Rust HDL.
> > Rust has a rather non-verbose binding to python: https://pyo3.rs/
>
>
> It looks like it's a crude/lowlevel near-direct interface to the c python
> module API. I recognise the data structure names and the "GIL". Global
> something Lock.
>
global interpreter lock

>
> It'd be a handful. The python c interface has some crucial conventions
> which if not obeyed result in crashes and memory leaks. It's a pain to work
> with, only worth it if you seriously need speed.
>
the library uses rust lifetimes to take care of almost all the issues with
ownership, memory leaks, and locking/unlocking the GIL. The locations where
you have to be careful about locking, memory, or undefined behavior are
marked with the "unsafe" keyword (standard practice in rust) and, from what
I recall, most of the api is marked as safe. This all makes the api much
easier to use than you might expect (though I haven't used it myself).

>
> L.
>
>
> > On Sun, Mar 17, 2019, 07:18 Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > On Sun, Mar 17, 2019, 07:14 Luke Kenneth Casson Leighton <
> lkcl at lkcl.net>
> > > wrote:
> > >
> > >> Example of the polymorphic benefits of python which I plan to exploit
> is
> > >> in
> > >> the pipeline Stage API. Use m.d.comb += self.idata.eq(self.idata) and
> if
> > >> odata is an object or a signal it does not matter.
> > >>
> > >> The API requirement becomes that if it is an object then the eq
> function
> > >> must return a *list* of eq assignments of all of the signals within
> that
> > >> class instance that will get the assignment of the idata object
> signals
> > >> into odata.
> > >>
> > >> Strong typing actually massively interferes with this type of
> > flexibility
> > >> as it is unexpected and unanticipated legitimate *and desirable*
> > behavior
> > >> that not even the authors of nmigen could have predicted, and strong
> > >> typing
> > >> would prevent and prohibit unless explicitly envisaged, way, way in
> > >> advance, which is almost impossible and impractical.
> > >>
> > > I think Rust can let you do that.
> > >
> > >>
> > >> This type of powerful shoot-yourself-in-the-foot capability of python
> is
> > >> just something that you need to put strict software engineering
> > practices
> > >> in place and adhere to them no matter what.
> > >>
> > >> 15 years ago I genuinely used to think that unit tests were a total
> > waste
> > >> of effort. Then for pyjamas (the python to javascript language
> > translator)
> > >> we accumulated well over 20,000 of them and it was the only way that
> we
> > >> could safely make forward progress.
> > >>
> > >> As a team we managed some really quite significant fundamental
> > redesigns,
> > >> outputting completely different code, even with different performance
> > >> characteristics.
> > >>
> > >> L.
> > >>
> > >>
> > >> --
> > >> ---
> > >> crowd-funded eco-conscious hardware:
> https://www.crowdsupply.com/eoma68
> > >> _______________________________________________
> > >> libre-riscv-dev mailing list
> > >> libre-riscv-dev at lists.libre-riscv.org
> > >> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
> > >>
> > >
> > _______________________________________________
> > libre-riscv-dev mailing list
> > libre-riscv-dev at lists.libre-riscv.org
> > http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
> >
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>