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.