As it happens this is of interest to be, because I may have a use for MyHDL or something similar in a year or so. However, from this thread I'm a little confused about where the RPython toolchain would fit in. Sorry if I'm completely off-base here...
Presumably you want to keep your Python (2?) front end -- you wouldn't want application programmers using RPython directly, it is really tricky to write in as it's designed for a very specific use case which is very different from generic Python programming. I would guess that the reason for porting MyHDL to an RPython toolchain is that you don't just produce a flat Verilog file, but you also have a runtime system which simulates the Verilog (or the higher level Python description)? This sounds very interesting, I'm not sure how helpful the RPython GCs and JIT would be in your case, but it would be interesting to hear where you think a performance improvement can be made. You might have seen this paper on the PyPy status blog, on instruction set simulators: http://csl.cornell.edu/~cbatten/pdfs/lockhart-pydgin-ispass2015.pdf I don't think it is quite the same as your use case, but there are some interesting ideas in there. Cheers, Sarah On Mon, Mar 23, 2015 at 10:38 AM, Henry Gomersall <h...@cantab.net> wrote: > On 23/03/15 09:37, Maciej Fijalkowski wrote: > > On Mon, Mar 23, 2015 at 10:53 AM, Henry Gomersall <h...@cantab.net> > <h...@cantab.net> wrote: > > > On 23/03/15 08:33, Maciej Fijalkowski wrote: > > >>>> I must say we had quite a bit of a discussion and it seems we did not>> > understand what are you trying to achieve. What is the goal of what>> you're > doing? Translating MyHDL (or verilog) to rpython and compiling>> it? > Something else? Writing the converter itself in RPython? > > >> Ah, my apologies for not being clear. The goal is to translate RPython> > (MyHDL) to VHDL or Verilog.>> Essentially, the valid _convertible_ MyHDL > would have the constraint of> being restricted to RPython. This is > essentially a mix of hardware specific> types, some simple types and control > flow (it's inside a simple generator,> and the function is wrapped in a > decorator to provide some hardware specific> semantics, but I suspect this is > not helpful detail).>> So, we have a series of generators in which the > generator code, and all> types referenced inside the generator are either > written in RPython, or are> conceptually a base type (that is, a type that > should not be burrowed into> and is a direct representation of a hardware > feature), that describes the> activity of hardware.>> The intention would be > to use PyPy to translate these RPython blocks into> VHDL or Verilog.>> There > is support code that is normal python that surrounds these generators> which > is normal Python, but that is just essentially to set up the name> space and > attributes of the generator, which is then returned as the active> object.>> > Does that all make more sense?>> Cheers,>> Henry > > RPython does not emit verilog or vhdl. How are you going to address > that problem? Also, what precisely are you achieving by using RPython > toolchain? > > > No it doesn't. The VHDL/Verilog parts need to be written. > > There is a task of inferring flow from a restricted subset of Python, from > which V* can be generated. Any solution to the problem looks remarkably > like what I understand is being done by RPython. Would you suggest a better > strategy? > > The current solution is built on traversing the AST and special casing > certain inferred structures. The IR is never explicit and so it's hard to > do much with the flow graph. The concept is that by building on the RPython > flow object space as an intermediate representation, much more flexibility > can be added to the convertible code (e.g. inferring translated structures > from the IR, rather than from the code). > > Cheers, > > Henry > > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev > > -- Dr. Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
