myhdl-list

[myhdl-list] Further development setup

[Jan D. <ja...@ja...>]

It's time to set things up for new developments. There
are a number of issues that I'd like to describe.

Python 2.6
----------
I plan to move to Python 2.6. It's becoming the "sweet spot"
now and it's a necessary step to prepare for Python 3.0.

MyHDL 0.7
---------
Unfortunately, we're having a kind of a setback. The
conversion software was written using the "compiler" package.
This is deprecated in 2.6 and removed in 3.0. Instead,
the new package to use is "ast". This has the advantage
that it's closely related to the Python parser, but unfortunately
it requires a complete rewrite of the conversion code.

I have no idea how complicated this is going to be. I have
the tests, and an existing implementation of course, but
I don't expect it to be trivial.

Also, I'm not very motivated to support new things in the
convertor before the rewrite is done.

Mercurial named branches
------------------------
I plan to use named branches for the first time in mercurial,
to support simultaneous maintenance of 0.6 and further
development on the trunk. I believe this will be easier
for me than separate repositories.

It means that if you track the repository, you will have
to make sure to switch to the correct branch depending
on what you want to track.

More about this when it actually starts happening.


Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Further development setup

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> MyHDL 0.7
> ---------
> Unfortunately, we're having a kind of a setback. The
> conversion software was written using the "compiler" package.
> This is deprecated in 2.6 and removed in 3.0. Instead,
> the new package to use is "ast". This has the advantage
> that it's closely related to the Python parser, but unfortunately
> it requires a complete rewrite of the conversion code.

When I read the explanation about the compiler package at this page:

http://docs.python.org/library/compiler.html

It talks about that the compiler converts the Python code to an abstract
syntax tree and from there creates the Python bytecode.

Unfortunately I have not understood that process much deeper yet, but if
I recall it right, then the MyHDL converter uses the abstract syntax
tree to create the Verilog or VHDL code from. So the last step, the
Python bytecode is not really needed.

This makes me think whether it would make sense to take the compiler
package as part of myhdl? At least the part that parses Python code and
create the abstract syntax tree. This would ease the requirement to
change the conversion software in the time line of Python 2.6.

Guenter

Re: [myhdl-list] Further development setup

[Jan D. <ja...@ja...>]

Günter Dannoritzer wrote:

> When I read the explanation about the compiler package at this page:
> 
> http://docs.python.org/library/compiler.html
> 
> It talks about that the compiler converts the Python code to an abstract
> syntax tree and from there creates the Python bytecode.
> 
> Unfortunately I have not understood that process much deeper yet, but if
> I recall it right, then the MyHDL converter uses the abstract syntax
> tree to create the Verilog or VHDL code from. So the last step, the
> Python bytecode is not really needed.
> 
> This makes me think whether it would make sense to take the compiler
> package as part of myhdl? At least the part that parses Python code and
> create the abstract syntax tree. This would ease the requirement to
> change the conversion software in the time line of Python 2.6.

Both packages, compiler and ast, generate an abstract syntax tree
and support walking through it. None of them is used by the built-in
Python compiler. However, ast starts from the same syntax description
as the built-in compiler, so it is closer to the real thing.

The problem is that these packages have to be adapted whenever the
Python syntax changes by extensions (typical in major releases) or
fundamental changes (3.0).

What will happen with 3.0 is that package compiler simply won't support
that Python syntax. Therefore, we have no choice to move to the
ast package if we want to stay current.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com