Hi, On Mon, Mar 23, 2015 at 12:41 PM, Henry Gomersall <h...@cantab.net> wrote: > On 23/03/15 12:10, Sarah Mount wrote: >
<snip> > Well, users currently _are_ restricted to a small subset of "convertible" > python. I would suggest this is actually more restrictive than RPython. I > suppose the question I have is what happens at the boundary with RPython - > can one construct an object that is crosses the boundary, with some RPython > only methods and some general Python methods? Ah, my mistake. > It's worth noting the MyHDL is several overlapping things. It's first and > foremost a library for representing hardware concurrency. If a developer is > restricted to only a small subset of valid Python and types, the blocks that > are described using MyHDL constructs can be converted into VHDL or Verilog. > It allows very neat workflow - one has the full power of Python for defining > behaviour, and then one writes the convertible code (which is verified > against the behavioural model), and then one cosimulates the converted code, > verifying that is doing the write thing (using a Verilog/VHDL simulator). > Thanks, that has certainly clarified things for me. > > 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. > > Well, potentially, but the big win is in being allowed a broader range of > convertible constructs. For example, there is currently no way to handle > general iterables (only loops of the form `for i in range(N):` are allowed). > Clearly, this is very restrictive for writing nice, expressive code. > > Stepping back a minute. The ultimate goal IMO would be a tool that takes a > MyHDL instance block (that is, that represents the function of a hardware > block), along with the associated static namespace, and converts into > something that downstream tools can understand (VHDL or Verilog), with as > much expressive power in the code as makes sense given the target > restrictions. > Hmm. So, what I understand from this is that your current front-end implements a very small subset of Python, you have noticed that RPython implements a slightly larger subset of Python, so you want to replace your front-end and maybe some internals with the RPython equivalents? I'm not sure how well this will work. For one thing, RPython is intended to be translated to a native format (i.e. you take a description of an interpreter or VM in RPython and after a very long compile you get a native executable that is your interpreter, with any RPython internals, such as JITs and GCs, included). I'm not sure if this is a win for you or not, because I'm not sure if an RPython front-end can really be made to fit a MyHDL back-end, without just re-writing the whole thing as an interpreter. Cheers, Sarah -- 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
