Re: [Iverilog-devel] bugs/enhancements in iverilog

[Cary R. <cy...@ya...>]

 I have subsequently checked and we match at least one of the big 3 for how @ is handled so that's not a bug, but this was more a question how do we want to handle extension in general. For example: binary ~& and ~| and the number of pullup/down ports. I assume we should as a minimum report these as extensions unless the user has deemed them acceptable.
So I think we have the following choices and we need to decide which path to take:
1. Not allow extension by default, but they can be enabled either individually or globally. This gives the maximum portability, but we miss out on enhanced functionality if portability is not a concern.

2. Allow the extensions by default and generate compile time warnings unless the warning is disabled either individually or globally. Do we also need a flag to disable extensions? I assume this would just turn the portability warnings into errors.
My personal preference is for #2 with the ability to disable extensions when portability is needed. Also if #2 is implemented getting #1 is just flipping the default setting of the global disable flag which would make changing our mind in the future trivial. Does anyone else have an idea how we should handle this? I think getting this designed well in the beginning is important.

Cary


    On Saturday, May 16, 2020, 2:53:24 PM PDT, Stephen Williams <st...@ic...> wrote:  
 
 It makes sense to be strict about the syntax. There are likely lots of
people who learn Verilog syntax from Icarus Verilog behaviors.

The "@ *" vs. "@*" might be construed as an actual bug. If that's the
case, then I would suggest NOT accepting the extended version, even in
a generous mode. However, you are really going to have to convince me
that @* is a single token. Pretty sure that is not the case. The
standard has in the beginning an exhaustive list of all the lexical
tokens, and @* is not listed there. Also, consider that @* and @(*)
are specifically called out as valid.

On Mon, May 11, 2020 at 12:38 AM Cary R. via Iverilog-devel
<ive...@li...> wrote:
>
> I have found a couple things that could be considered enhancements, but are clearly not supported by the standard. My question is should we have these enhancements controlled by a flag of some sort so people can restrict Icarus to only accept what is supported by the standard? For example pullup/pulldown should only support a single port. @* is really a single token and the binary ~& and ~| are not in the standard. There may be more. Is some new strict flag the correct thing for this? I think @* not being a single token is a bug and probably should be fixed. I'm personally of the opinion only standard/commonly supported functionality should be enabled by default and an extension flag should be used to enable the rest of this if it is kept.
>
> This would likely require reworking some of the tests to pull out the enhancements to have them be in a separate file.
>
> Thoughts?
>
> Cary
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel



-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel