[pypy-dev] Custom types for annotating a flow object space

[Henry Gomersall]

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