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

[Henry Gomersall]

On 23/03/15 12:10, Sarah Mount wrote:
> 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.

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?

It might be that code that is RPython compliant cannot also use 
necessary MyHDL constructs, though there may well be workarounds (it 
would almost certainly not be the case that the code is too flexible).

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).

>
> 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.

All these things are possible in the current approach, but I've been 
wondering if the similar functionality of similar tools can be used to 
do some of the heavy lifting. The current approach is essentially trying 
to implement a "MyHDL restricted" python to VHDL/Verilog translator.

> 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 
> <http://csl.cornell.edu/%7Ecbatten/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.

That's interesting. I had seen it but not really noticed it's relevance.

Cheers,

Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150323/9f7e84b0/attachment.html>