Date: Fri Jul 13 2007 - 00:52:53 PDT
Listing the incremental additions for each version instead of the full list for each version would considerably reduce the space required. Shalom ________________________________ From: Gran, Alex [mailto:alex_gran@mentor.com] Sent: Thursday, July 12, 2007 10:29 PM To: Bresticker, Shalom; Rich, Dave; sv-bc@server.eda.org Subject: RE: [sv-bc] lrm compiler directive order While we are looking at this, we might also consider the issue which was discussed previously here http://www.eda-stds.org/sv-bc/hm/5979.html And relates to Mantis 1846 and 1826 Right now the `begin_keywords entry has tables of all the sets of keywords. 1846 suggests not having a duplicate entry of the 1800-2008 keywords, but rather a reference to the Appendix 1826 appears to suggest rather than listing all the keywords for each version, just list the new additions With listing the entries in alphabetical order, it puts `begin_keywords at the top. Which is fine, I just wonder if there is a way to avoid having 4 pages dedicated to nothing but tables of keywords right at the begin of the section. ~Alex ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Thursday, July 12, 2007 12:00 AM To: Rich, Dave; sv-bc@server.eda.org Subject: RE: [sv-bc] lrm compiler directive order OK, that would bring us to something like this: 21. Compiler Directives 21.1 General 21.2 Overview 21.3 Text-processing directives 21.3.1 `begin_keywords, `end_keywords 21.3.2 `define, `undef 21.3.3 `ifdef, `ifndef, `else, `elsif, `endif 21.3.4 `include 21.3.5 `line 21.4 Other directives 21.4.1 `celldefine, `endcelldefine 21.4.2 `default_nettype 21.4.3 `pragma 21.4.4 `resetall 21.4.5 `timescale 21.4.6 `unconnected_drive, `nounconnected_drive How is that ? Thanks, Shalom ________________________________ From: Rich, Dave [mailto:Dave_Rich@mentor.com] Sent: Thursday, July 12, 2007 4:48 AM To: Premduth Vidyanandan; Gran, Alex; Bresticker, Shalom; sv-bc@server.eda.org Subject: RE: [sv-bc] lrm compiler directive order I would at least like to see them split into text processing directives, and then all the other semantic altering directives. Dave ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Premduth Vidyanandan Sent: Wednesday, July 11, 2007 1:41 PM To: Gran, Alex; Bresticker, Shalom; sv-bc@server.eda.org Subject: RE: [sv-bc] lrm compiler directive order Hi, I would like to vote to brining it back to the alphabetical order as Shalom suggests. Thanks Duth ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gran, Alex Sent: Wednesday, July 11, 2007 12:16 PM To: Bresticker, Shalom; sv-bc@server.eda.org Subject: RE: [sv-bc] lrm compiler directive order I don't have a very strong opinion on this. So if others do feel strongly one way or another I will happily back down. I tend to like having `define, `include and `ifdef towards the top because these seem to directives that are more commonly used. Where as at least in code I've seen from users `pragma and `begin_keywords are not as often used, so I'm fine with them being at the bottom of the section. ~Alex ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Wednesday, July 11, 2007 5:17 AM To: sv-bc@server.eda.org Subject: [sv-bc] lrm compiler directive order Hi, In 1364-1995, compiler directives were ordered in the LRM alphabetically. (Some directives were described in the same subclause as another, and then the order went by the first directive in the subclause.) In 1364-2001, the order was almost preserved, except that somehow `line got into the wrong place. 1364-2005 messed up by adding `pragma and `begin_keywords at the end. Now P1800 doesn't seem to have any particular order. Can we go back to the alphabetical order? Thanks, Shalom -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
