[Libre-soc-bugs] [Bug 980] Implement C-based Power ISA pseudocode compiler

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=980

--- Comment #12 from Dmitry Selyutin <ghostmansd at gmail.com> ---
I've spent a LOT of hours debugging and checking the opportunities. Here are
some conclusions I came to so far.


1. I might appear to be a devil's advocate, but I actually think that
python-ply is a good choice. Regardless of our implementation pros and contras,
for me it already advocates python-ply as a sufficiently good instrument, and
I'm going to stick with it.
2. What is bad from C code generation perspective is that we produce Python
AST. It's not a suitable candidate for C code generation. What's worse, we
generate multiple nodes for a single entity, and it gets too complicated even
in Python, not even speaking of C.
3. It gets especially hairy when we produce Python calls and modify the code
after it has been obtained with AST. That is, we get the AST result and patch
it in place.
4. We cannot avoid modifying the nodes produced, but there are several issues.
First, all our nodes are Python AST. Second, some nodes are built in place,
e.g. concat and selectassign and many others (basically all which lead to
ast.Call). Third, whenever I'll update this code, this would potentially bring
a disaster.

All in all, I don't believe that the current code is a good basis for C code
generator. It works for Python, and I'd keep it so that the code WORKS.


Here's what I suggest instead.
1. Keep the python-ply, but recreate the overall code so that it produces
CUSTOM nodes instead. That is, where we have <u, there will be a `class
LTUnsigned(Node)` construction, similarly for all other stuff. Basically the
real language-agnostic AST. Language-agnostic is an absolutely critical item!
2. Once we have AST collected and working, we can have walkers and visitors for
it.
3. This AST can be used for C code generation. Ideally, had we not time
constraints, we'd build ANOTHER AST atop of that: PseudocodeAST => CAst. But
for now likely we'll have to follow the simpler approach.
4. If we have time and opportunities, we'd just eventually follow the same
approach for Python code. That is, just convert PseudocodeAST to ast.Module.


I don't think it's doable in terms of the current approach mostly due to the
fact that it produces a pretty complicated Python AST. I could try changing the
current code, but I'm absolutely sure my changes will make all the code around
completely nuts.


I wish I had returned with a more encouraging news, but these are conclusions
I've been able to reach so far. Basically my suggestion is to use python-ply
again and output a completely different nodes. So the code eventually will look
familiar but still build something completely different.


I'd like to know your opinion and will meanwhile move on with checking other
projects using ply to better understand how it can be used. Before we proceed,
two important items: 1) python-ply is to stay, we don't have time for brand new
frameworks, plus I'm mostly satisfied with it; 2) no there's no time (and
there's a strong lack of desire) to teach the whole Python ast to produce
Python code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.