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

Ronan Lamy ronan.lamy at gmail.com
Sun Mar 22 22:45:54 CET 2015


Le 22/03/15 20:02, Henry Gomersall a écrit :
> I'm looking at using PyPy's flow object space for an experimental
> converter for MyHDL (http://www.myhdl.org/), a Python library for
> representing HDL (i.e. hardware) models. By conversion, I mean
> converting the MyHDL model that represents the hardware into either
> Verilog or VHDL that downstream tools will support. Currently, there is
> a converter that works very well in many situations, but there are
> substantial limitations on the code that can be converted (much greater
> restrictions than RPython imposes), as well as somewhat frustrating
> corner cases.
>
> It strikes me that much of the heavy lifting of the conversion problem
> can be handled by the PyPy stack.
>
> My question then regards the following. MyHDL represents certain low
> level structures as python objects. For example, there is a notion of a
> signal, represented by a Signal object, that has a one to one mapping to
> the target HDL language. All the attributes of the Signal object
> describe how it should be converted. So, during annotation, the Signal
> object should be maintained as a base type, rather than burying deeper
> into the object to try and infer more about its type (which invariably
> breaks things due to RPython non-conformity). There are probably a few
> other types (though not many) that should be handled similarly.
>
> How does one instruct the translator to do this? Is it a case of writing
> a custom TranslationDriver to handle the custom types?

No, you simply need to register your Python types with the translator 
and describe their properties by subclassing some internal classes.
The interface is a bit complicated and requires some understanding of 
RPython's inner workings, but it works. rply has a good example of that: 
https://github.com/alex/rply/blob/master/rply/lexergenerator.py 
(specifically, the part that is guarded by 'if rpython:')

Here's how it works:
The ExtRegistryEntry tells the annotator to special-case Rule objects by 
annotating them as SomeRule(). SomeRule describes the annotator-level 
properties of Rule objects while RuleRepr tells the rtyper how to 
translate them to low-level (C-like) objects.

In your case, you definitely need an ExtRegistryEntry and a SomeSignal, 
but what to put in SignalRepr and whether you even need it depends on 
how you intend the Verilog/VHDL backend to work.


More information about the pypy-dev mailing list