>SVDB 329 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=329 > >SVDB 1338 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1338 > >SVDB 1339 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1339 > >SVDB 1548 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1548 > >SVDB 1571 ___Yes _X_No >http://www.eda.org/svdb/view.php?id=1571 I am not sure we have resolved all the existing issues with macros. I am hesitant to add any extensions until we have resolved all of those. I don't see this functionality as critical, since it can be gotten by defining another wrapper macro with fewer arguments, which invokes the original macro with the desired defaults for the extra arguments. I also do not see the situation with macros as being quite the same as functions. With functions, it is clear when you are leaving out an argument, and it is clear that something needs to be provided instead. With a macro, the argument is text, and empty text is valid text. One symptom of this is the issue that white space is being considered to be an empty argument. That makes it dependent on the proposal to strip white space from the front and back of arguments. Otherwise white space is a perfectly valid non-empty argument that you may want substituted. I see an issue with the description of the expansion ordering, with respect to the definition of what constitutes a recursive macro. As Greg pointed out, the original example where a `TOP invocation was used as an actual argument of a `TOP invocation, is not recursive. It is composition of the macro with itself, not recursion. The new use of the macro is coming from the argument, not from the macro body. It does not create any issues with infinite recursion. But with the description of substituting the actuals into the macro text before expanding them (though I think that is the right thing to do), the macro is expanding into text containing a usage of itself. The LRM says that this is erroneous, and a recursive macro. In a sense, this issue was already there, but it has been made more severe because of the explicit description of the expansion order. I also have a problem with the statement that the argument expansion shall not introduce new uses of the formal. That wording implies that it is possible but illegal to do this. What is intended is that it is not possible to do this, because text that expands into an identifier that matches a formal is not considered to be a use of the formal after the actuals have been substituted. Just because the word "shall" is supposed to be used in some situations does not mean that it should be used in all situations. It has a very specific meaning in the LRM. >SVDB 1619 ___Yes _X_No >http://www.eda.org/svdb/view.php?id=1619 I still have some concerns with some of the wording. On reading the proposal, I also realized that there is some potential for visual confusion between default values for input ports and initializers for output ports. I had not noticed previously that initializers were allowed for output ports. Given the rules for implicit port directions and inheriting port directions, the direction of a port may not always be immediately obvious. A reader could then easily confuse a default value with an initializer, and then have trouble understanding why their port is not behaving as they expect. I don't know if this is a big issue, but it is one I had not noticed before. >SVDB 1957 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1957 > >SVDB 2102 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2102 > >SVDB 2106 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2106 Though I would suggest that "non-hierarchal" be replaced with "non-hierarchical", to match the rest of the LRM. >SVDB 2152 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2152 > >SVDB 2163 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2163 > >SVDB 2169 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2169 > >SVDB 2170 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2170 > >SVDB 2178 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2178 > >SVDB 2184 ___Yes _X_No >http://www.eda.org/svdb/view.php?id=2184 As has been pointed out by others, the query functions cannot simply be added to the list, as the conditions under which they are constant are different. Their arguments must be fixed-size types, rather than constant expressions. >SVDB 2217 ___Yes ___No _X_Abstain >http://www.eda.org/svdb/view.php?id=2217 While the proposal seems reasonable enough, I have not had enough time to fully consider it. If the people involved in the discussions on name resolution are OK with it, then I will accept their judgement and not oppose it. I do notice that in the description of the resolution of dotted name 4, it says "the name f.x" instead of "the name f2.x". This should be fixed. Also, the change to rule b) in 22.7 still leaves an incorrect description. It says to look in the parent module's outermost scope. That was true before generates. But with generates, it should look in the scope where it was instantiated in its parent, which may be a generate scope rather than the outermost scope. It should then search upwards through any nested generate scopes until it reaches the parent's outermost scope. But that problem is independent of this Mantis item. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Dec 1 18:28:41 2007
This archive was generated by hypermail 2.1.8 : Sat Dec 01 2007 - 18:29:14 PST