Re: [Iverilog-devel] vhdlpp update

[Kevin C. <iv...@gr...>]

I've done recursive descent (RD) on C++, it can't be worse than that. I just tokenize everything according to the context then do RD on the token stream - ideally I'd be able to parallel process chunks snipped of the stream, but I never got that far.

I don't use lexx/yacc/bison etc. - it's bad enough reading human generated code, debugging those is way too painful. With RD you can tell where you are when things go wrong, and it's easier to handle corner cases. It's particularly easy when the beginning and end of blocks are clearly marked.

Someone at Synopsys was claiming that the reason for not doing something was "keyword incompatibility" - that's the lamest of excuses, and just means they're clueless about writing parsers.

Kev.

On 04/26/2015 08:33 AM, Stephen Williams wrote:
>
> Um...
>
> 1) VHDL is definitely NOT suitable for recursive descent parsing.
> Few modern computer languages are.
>
> 2) If you integrate left context into your lexor, then yes a LALR
> parser, and bison in particular, would have an easier time directly
> mapping. Oh wait, that's almost what we do by matching these things
> as IDENTIFIERS and handling them in the rules. We just do it outside
> of the flex/bison infrastructure.
>
> You have a point that TRUE and FALSE may be enumeration values.
> It turns out that they are, and they are defined in the BOOLEAN
> type enumeration in the standard package. Orson, this is something
> you need to take note of. While they are not keywords, they ARE
> predefined enumeration values. There is infrastructure in vhdlpp
> for predefining types, that is what you want to use here.
>
>
> On 04/25/2015 11:30 AM, Kevin Cameron wrote:
>
> > The whole keyword thing is just a consequence of how people did
> > parsers - if you use context aware recursive-descent parsers then
> > there isn't a problem.
>
> > One useful thing that VHDL does is that it moved a lot of stuff to
> > user-space by putting it in "standard headers". You don't have to
> > take the LRM literally, and you can move things like "true" &
> > "false" to enum in a header file.
>
> > The LRMs are really just statements of what you need to understand
> > to be compatible, you can implement your version with more/better
> > capabilities.
>
> > Kev.
>
> > On 04/23/2015 08:35 AM, Stephen Williams wrote:
> >> On 04/23/2015 07:16 AM, Maciej Sumiński wrote:
> >>> I have one doubt regarding the proposed branch. It introduces a
> >>> few new keywords (true, false, note, warning, error, failure).
> >>> Because of that, it is impossible to use them as names, so for
> >>> example you cannot have a signal called 'true', which should be
> >>> technically valid according to the VHDL standard.
> >>
> >> If the word is not a reserved word as listed in the IEEE1076
> >> standard, then it cannot be parsed as a keyword. It needs to be
> >> matched as an IDENTIFIER and interpreted during semantic
> >> analysis. This is one of the painful quirks of VHDL.
> >>
> >> So no, you cannot add new keywords. Match them as IDENTIFIERs,
> >> then check the actual value in the rules where you expect them.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel