On 23/03/15 12:50, Sarah Mount wrote: <snip>
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.
So, the thinking initially, which I still think might be the route to go, is to tap in to the flow object space. Having a really good representation of the flow graph would be hugely useful in generating the relevant HDL code. If it's possible to also tap into some of the annotation code, this might be useful, but then again it might not :) Cheers, Henry