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
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
