iverilog-devel

[Iverilog-devel] preprocessor abuse?

[Larry D. <ldo...@re...>]

Guys -

I'm often tempted to produce patches like the one appended.
I don't know how hostile the reaction will be.  If you don't
like it, just say so.

The advantages include compactness, ease of extension, and
intrinsic self-consistency.  It might also be considered more
opaque and harder to debug, but there are lots of things like
that buried in Icarus, so maybe it doesn't matter.  :-p

This patch doesn't affect the size of the object code.
That can be accomplished with a loop and a data structure,
where the data structure itself uses some preprocessor work.
Untested concept:

struct {bool *flag, const char *name} debug_entry;
struct debug_entry debug_flag_table[]={
#define ENTRY(x) { &debug_##x, #x}
	ENTRY(scopes),
	ENTRY(eval_tree),
	ENTRY(elaborate),
	ENTRY(synth2)
#undef ENTRY
};

   - Larry

--- verilog/main.cc	2008-02-06 15:19:07.000000000 -0800
+++ /home/ldoolitt/src/verilog-0.9/main.cc	2008-02-06 15:42:15.000000000 -0800
@@ -356,20 +356,14 @@
 		  basedir = strdup(cp);
 
 	    } else if (strcmp(buf, "debug") == 0) {
-		  if (strcmp(cp, "scopes") == 0) {
-			debug_scopes = true;
-			cerr << "debug: Enable scopes debug" << endl;
-		  } else if (strcmp(cp,"eval_tree") == 0) {
-			debug_eval_tree = true;
-			cerr << "debug: Enable eval_tree debug" << endl;
-		  } else if (strcmp(cp,"elaborate") == 0) {
-			debug_elaborate = true;
-			cerr << "debug: Enable elaborate debug" << endl;
-		  } else if (strcmp(cp,"synth2") == 0) {
-			debug_synth2 = true;
-			cerr << "debug: Enable synth2 debug" << endl;
-		  } else {
-		  }
+#define DEBUG_FLAG(x) (strcmp(cp, #x) == 0) {debug_##x = true; \
+	cerr << "debug: Enable " #x " debug" << endl;}
+		       if DEBUG_FLAG(scopes)
+		  else if DEBUG_FLAG(eval_tree)
+		  else if DEBUG_FLAG(elaborate)
+		  else if DEBUG_FLAG(synth2)
+		  else { }
+#undef DEBUG_FLAG
 
 	    } else if (strcmp(buf, "depfile") == 0) {
 		  depfile_name = strdup(cp);

Re: [Iverilog-devel] preprocessor abuse?

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

--- Larry Doolittle <ldo...@re...> wrote:
 
> struct {bool *flag, const char *name} debug_entry;
> struct debug_entry debug_flag_table[]={
> #define ENTRY(x) { &debug_##x, #x}
> 	ENTRY(scopes),
> 	ENTRY(eval_tree),
> 	ENTRY(elaborate),
> 	ENTRY(synth2)
> #undef ENTRY
> };

If you use a name that describes what is actually going on I think this is
fine and can make it easier to understand what is going on. I would make
the above DEFINE_ENTRY. Also since you go to the trouble to undef the
macro why not also check that it is not already in use before you define
it? This would prevent the accidental redefinition of a macro that could
cause problems later in the code.

I would also suggest adding some extra space to make it more clear where
the macro definition and the use starts and add a single line comment
describing what the macro does "/* ENTRY(scopes) produces { &debug_scopes,
scopes} */". The comment should help with the opacity.

To me it's all about making the intent of the code clearer. If a macro
does that I say go for it.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Iverilog-devel] preprocessor abuse?

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Mixed feelings here about the use of macros. My gripe is that
they often make opaque what's going on. I think the example below
is not something I would reject as it doesn't suffer that ill.

I add though that I prefer macros over ifdef's and templates
and/or inline functions over macros, although functions/templates
don't work sometimes where macros are usefully used.

Larry Doolittle wrote:
> Guys -
> 
> I'm often tempted to produce patches like the one appended.
> I don't know how hostile the reaction will be.  If you don't
> like it, just say so.
> 
> The advantages include compactness, ease of extension, and
> intrinsic self-consistency.  It might also be considered more
> opaque and harder to debug, but there are lots of things like
> that buried in Icarus, so maybe it doesn't matter.  :-p
> 
> This patch doesn't affect the size of the object code.
> That can be accomplished with a loop and a data structure,
> where the data structure itself uses some preprocessor work.
> Untested concept:
> 
> struct {bool *flag, const char *name} debug_entry;
> struct debug_entry debug_flag_table[]={
> #define ENTRY(x) { &debug_##x, #x}
> 	ENTRY(scopes),
> 	ENTRY(eval_tree),
> 	ENTRY(elaborate),
> 	ENTRY(synth2)
> #undef ENTRY
> };
> 
>    - Larry
> 
> --- verilog/main.cc	2008-02-06 15:19:07.000000000 -0800
> +++ /home/ldoolitt/src/verilog-0.9/main.cc	2008-02-06 15:42:15.000000000 -0800
> @@ -356,20 +356,14 @@
>  		  basedir = strdup(cp);
>  
>  	    } else if (strcmp(buf, "debug") == 0) {
> -		  if (strcmp(cp, "scopes") == 0) {
> -			debug_scopes = true;
> -			cerr << "debug: Enable scopes debug" << endl;
> -		  } else if (strcmp(cp,"eval_tree") == 0) {
> -			debug_eval_tree = true;
> -			cerr << "debug: Enable eval_tree debug" << endl;
> -		  } else if (strcmp(cp,"elaborate") == 0) {
> -			debug_elaborate = true;
> -			cerr << "debug: Enable elaborate debug" << endl;
> -		  } else if (strcmp(cp,"synth2") == 0) {
> -			debug_synth2 = true;
> -			cerr << "debug: Enable synth2 debug" << endl;
> -		  } else {
> -		  }
> +#define DEBUG_FLAG(x) (strcmp(cp, #x) == 0) {debug_##x = true; \
> +	cerr << "debug: Enable " #x " debug" << endl;}
> +		       if DEBUG_FLAG(scopes)
> +		  else if DEBUG_FLAG(eval_tree)
> +		  else if DEBUG_FLAG(elaborate)
> +		  else if DEBUG_FLAG(synth2)
> +		  else { }
> +#undef DEBUG_FLAG
>  
>  	    } else if (strcmp(buf, "depfile") == 0) {
>  		  depfile_name = strdup(cp);
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 


- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHqlGZrPt1Sc2b3ikRAoANAJ45ha6uTjFkDiNumqVXSJXcdCetSgCgzVJ+
go6r/2hCnzHlaQwQ6rmSST0=
=wWtm
-----END PGP SIGNATURE-----