[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 #38 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #37)
> > Still I think this would be the right choice, and eventually will do it.
> 
> i like the very deliberatte brutal simplicity of the current parser. however
> an actual AST (esp. in BNF form) is ultimately better but hm the lexer/parser
> split in python-ply leaves me drumming my fingers at the additional
> complexity.

I think we should aim more for an intermediate representation that aims to
capture the *semantics* (since those are what we're trying to translate) more
than trying to exactly match the *syntax*, so, no, I don't think an AST is
appropriate, we should instead make a tree structure that may be similar to an
AST but instead prioritizes captures semantic differences over being in BNF
form or other syntax-focused requirements.

An example of what I mean:

the difference between FPSCR[VXSNAN] (a named field access, not indexing,
usually written FPSCR.VXSNAN) and v[i + 3] (bit indexing) -- if we were focused
on syntax those would both just be the indexing operator with subexpressions of
FPSCR and VXSNAN, or v and i + 3 respectively. Focusing on semantics means
those would instead be different node kinds, since they are completely
different kinds of operations. FPSCR[VXSNAN] probably would be the same kind of
node as FPSCR.VXSNAN with a flag if necessary to tell the two syntactical forms
apart.

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