iverilog-devel — Conversations on matters of Icarus Verilog development

[Iverilog-devel] Claiming some files.

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

If possible I want to claim the following files for a week or so. I
started some major reorganizations/rewrites and to make all our lives
easier it would be best if I'm the only one changing them for a while.

elab_expr.cc, elab_net.cc, expr_synth.cc and to a lesser extent netmisc.*.

I'm working on consistency between the different expression code handlers,
factoring out common code, adding some constant conversions (decimal to
real), adding some missing optimizations and reworking the error code to
only emit a message for the actual error and for the statement as a whole.
So basically if you generate a zero pointer you must also print a message
and increment the error count. If all you are doing is propagating a zero
no message will be printed.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Iverilog-devel] On Spaces and Tabs

[Steven W. <st...@in...>]

I'm not a contributor to Steve's C++ code base but I do have to deal 
with LOTS of Verilog code from different sources since I'm a consulting 
engineer. I make my living working on other people's code.

I'm also a VI user (old habits are hard to break.)

That being said - I've seen more unreadable code due to tabs than I can 
tell you.  I've literally had to reformat code by hand to make it 
readable/understandable before I could deal with it.

Looking at Steve's style statement AND Larry's point that it's Steve's 
codebase - I think you have your decision right there.

Keep up the good work guys!

Steve Wilson

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Larry Doolittle wrote:
>   
>> Guys -
>>
>> On Sun, Feb 17, 2008 at 12:19:12PM -0800, Cary R. wrote:
>>     
>>> --- Michael Witten <mfw...@MI...> wrote:
>>>       
>>>> However, that was an uncharacteristic outburst of enthusiasm
>>>> for tabs, which I've tried to use of recent.
>>>>         
>>> Tabs save space and depending on your setup key strokes as well, but in
>>> todays world I'm not so certain that the space savings is an issue and
>>> many editors can be configured to automatically convert tabs and spaces
>>> depending on preference.
>>>       
>> I'm almost embarrassed to have brought up the subject in the first
>> place.  If the choice is between reliable, inconsistently spaced code,
>> and buggy beautiful code, I'll take the former every time.
>>     
>
>   
stuff deleted for brevities sake.

Re: [Iverilog-devel] On Spaces and Tabs

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

Steve -

On Mon, Feb 18, 2008 at 11:45:03AM -0800, Stephen Williams wrote:
> [chop] But I do insist that the code should be viewed
> the way the writer wrote it. In particular, it bothers me immensely
> when I see source code clearly written by a vi user with tabs set to
> 4. It's unreadable! Either do not use tab characters (i.e. leading
> spaces instead) or stick to the standard tab=8 and use tab followed
> by spaces to get the desired position.
> 
> I think the above pretty much rules out BusyBox coding style as I grasp
> them from this conversation since an 8-place tab for every indent would
> be hopelessly too deep for code with any nesting complexity.

There are two orthogonal answers for this:

1. Don't indent so deeply.

2. Set your tab=6.

> Expecting code format to survive viewers adjusting indent for
> personal taste is unrealistic.

Properly used, the busybox style looks fine no matter what
you set your tabstops to.  Don't take my word for it, open
up a recent copy of busybox and see how it looks.  Try it
with tab=4, tab=6, and tab=8.  Then re-read the busybox style
guide to see how it's done.

Specifically, the first file I looked at is coreutils/expand.c.
It gets up to about 6 indent levels, and mostly fits into
80 columns at tabs=8.  I'm sure Steve will like its look
better at tabs=6, and you can de-emphasize the nesting (and make
the longest line fit 80 columns) by setting tabs=2.  There are
a couple of places where spacing within the line is important,
and that's done with spaces: see the initial comment block, the
enum declaration of OPT_{INITIAL,TABS,ALL}, and the declarations
of {,un}expand_longopts[].

The point is kind of like original (pre-commercialization and
pre-web-designer) html concept: encode semantics in the document,
in this case by using a number of tabs to represent nesting level.
Presentation (physical spacing) is left up to the browser and
individual choice.

   - Larry

Re: [Iverilog-devel] On Spaces and Tabs

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

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

Larry Doolittle wrote:
> Guys -
> 
> On Sun, Feb 17, 2008 at 12:19:12PM -0800, Cary R. wrote:
>> --- Michael Witten <mfw...@MI...> wrote:
>>> However, that was an uncharacteristic outburst of enthusiasm
>>> for tabs, which I've tried to use of recent.
>> Tabs save space and depending on your setup key strokes as well, but in
>> todays world I'm not so certain that the space savings is an issue and
>> many editors can be configured to automatically convert tabs and spaces
>> depending on preference.
> 
> I'm almost embarrassed to have brought up the subject in the first
> place.  If the choice is between reliable, inconsistently spaced code,
> and buggy beautiful code, I'll take the former every time.

It's become pertinent these days as more and more people are
contributing. Here's my take on indent styles.

My take on tabs vs. spaces comes from somewhat older (maybe "historic")
GNU standards mixed in with personal experience and pragmatism. I'm
not stuck-up about it. But I do insist that the code should be viewed
the way the writer wrote it. In particular, it bothers me immensely
when I see souce code clearly written by a vi user with tabs set to
4. It's unreadable! Either do not use tab characters (i.e. leading
spaces instead) or stick to the standard tab=8 and use tab followed
by spaces to get the desired position.

I think the above pretty much rules out BusyBox coding style as I grasp
them from this conversation since an 8-place tab for every indent would
be hopelessly too deep for code with any nesting complexity. Expecting
code format to survive viewers adjusting indent for personal taste is
unrealistic.

As for the actual indent position for each level of nesting, I tend
to use 6, although I will sometimes shrink that to keep lines from
falling too far off the end. The rest is pretty much an accident of
my emacs configuration:-P
- --
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

iD8DBQFHueA/rPt1Sc2b3ikRAiZ+AKDW7PJDt3mzYZ7zCqq03PfmeeY+YwCeMagj
cevlyt/GvnHF+YBskmVwprc=
=FtqO
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] On Spaces and Tabs

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

Guys -

On Sun, Feb 17, 2008 at 12:19:12PM -0800, Cary R. wrote:
> --- Michael Witten <mfw...@MI...> wrote:
> > However, that was an uncharacteristic outburst of enthusiasm
> > for tabs, which I've tried to use of recent.
> 
> Tabs save space and depending on your setup key strokes as well, but in
> todays world I'm not so certain that the space savings is an issue and
> many editors can be configured to automatically convert tabs and spaces
> depending on preference.

I'm almost embarrassed to have brought up the subject in the first
place.  If the choice is between reliable, inconsistently spaced code,
and buggy beautiful code, I'll take the former every time.

Let me try to add a few constructive comments, without getting bogged
down in details:

1. This is primarily Steve's code base.  The rest of us should adapt
our submissions to his style.

2. The busybox project is an example of a large multi-contributor
project that has a published, negotiated, and IMHO well-thought-out
policy on whitespace.  If Steve ever decides to change the whitespace
style, I highly recommend he start from there.

3. The patch in question doesn't diverge from Steve's whitespace style(s)
at all.  It merely fixes some typos in implementing that style.

4. Mixing whitespace changes with actual code changes in one patch is
bad version control practice.  Of course, if code is completely
rewritten, it doesn't matter how it is spaced, it's still picked up as
new code.

> > It is my belief that formatting plays an integral role in the
> > readability, maintainability, and understanding of code,

Agree.

> > so absolute control is therefore essential.

Disagree.  See busybox.

> > I would like to add that I don't believe code should be written as
> > though it's meant to be printed; that is, code should not be hard
> > wrapped unless absolutely necessary.

Meh.  Take this on a case by case basis.

> The question is at what width is this considered mandatory? I could use
> window widths much larger than 80, but when you get much larger than this
> it becomes harder to read and limits the number of windows you can have
> visible.

The question gets fuzzier if you use tabs for indentation.  What fits
on an 80 character screen with tabstop=4 may not fit for people like me
who set tabstop=8.  I occasionally (but rarely) write code that is best
expressed with very long lines.  I have been known to switch to tiny
font and stretch my window out to the max my screen can hold in order
to properly work on a file.  That's about 268 columns wide.

   - Larry

Re: [Iverilog-devel] On Spaces and Tabs

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

--- Michael Witten <mfw...@MI...> wrote:

> However, that was an uncharacteristic outburst of enthusiasm
> for tabs, which I've tried to use of recent.

Tabs save space and depending on your setup key strokes as well, but in
todays world I'm not so certain that the space savings is an issue and
many editors can be configured to automatically convert tabs and spaces
depending on preference.

> However, I've [re]convinced myself that spaces alone are the
> way to go, because they offer absolute formatting that is
> guaranteed to be the same in every editor; it should be simple
> to provide a script that warns people of mixed tabs and spaces.

Git, correctly, complains about spaces before tabs, but does not complain
about space after tabs. As a minimum I think it needs to be tabs, followed
by spaces. If we picked tabs only and six spaces per tab we would have a
problem with the case statements which are currently four spaces for the
condition and the normal six for the body.
 
> It is my belief that formatting plays an integral role in the
> readability, maintainability, and understanding of code, so
> absolute control is therefore essential.

I'm not entirely convinced leading tabs are bad, but I agree that
formatting like well placed comments are important. The hard part is not
cutting a corner now and then because you are in a hurry.

<snip>
 
> P.S.
> I would like to add that I don't believe code should be written as
> though it's meant to be printed; that is, code should not be hard
> wrapped unless absolutely necessary.

The question is at what width is this considered mandatory? I could use
window widths much larger than 80, but when you get much larger than this
it becomes harder to read and limits the number of windows you can have
visible. If there was an intelligent line wrap built into editors that may
be enough to have both long lines and reasonable screen widths.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

[Iverilog-devel] On Spaces and Tabs

[Michael W. <mfw...@MI...>]

I wrote the following earlier:
(http://sourceforge.net/tracker/index.php?func=detail
&aid=1894717&group_id=149850&atid=775999)
> I agree that standardization is essential. It should
> be something very simple.
>
> 	(1)	With all spaces, a great deal of control
> 		over the formatting is possible.
>
> 	(2)	Tabs take up less space and are usually
> 		the default (width 8) in most editors. I
> 		would suggest: All leading whitespace on
> 		a line should be tabs; most or all white-
> 		space after non-white space characters
> 		should be spaces.
>
> The number one rule should be: Write stuff that will
> look consistent in all editors.

However, that was an uncharacteristic outburst of enthusiasm
for tabs, which I've tried to use of recent.

However, I've [re]convinced myself that spaces alone are the
way to go, because they offer absolute formatting that is
guaranteed to be the same in every editor; it should be simple
to provide a script that warns people of mixed tabs and spaces.

It is my belief that formatting plays an integral role in the
readability, maintainability, and understanding of code, so
absolute control is therefore essential.

For instance, the alignment of the backslashes in the following
code is only guaranteed to be correct when nothing but spaces is
used for leading and trailing whitespace:

     #define YY_INPUT(buf,result,max_size) do {                 \
         if (istack->file) {                                    \
             size_t rc = fread(buf, 1, max_size, istack->file); \
             result = (rc == 0) ? YY_NULL : rc;                 \
         } else {                                               \
             if (*istack->str == 0)                             \
                 result = YY_NULL;                              \
             else {                                             \
                 buf[0] = *istack->str++;                       \
                 result = 1;                                    \
             }                                                  \
         }                                                      \
     } while (0)

Moreover, the code is presented as intended by the author.

Sincerely,
Michael Witten

P.S.
I would like to add that I don't believe code should be written as
though it's meant to be printed; that is, code should not be hard
wrapped unless absolutely necessary.

Re: [Iverilog-devel] Icarus memory problem (valgrind)

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

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

Cary R. wrote:
> Hi Steve,
> 
> Have you used valgrind or some other memory checker on Icarus? I was
> seeing a strange T0 problem with some of the real values so I installed
> valgrind to help track down the problem. I'm still working on that, but I
> also ran it on my integer tests and I appear to have found a small problem
> with user functions.

I have hot used valgrind. Others have, and have found and fixed bugs
as a result, so I believe it works, but I personally have not done it.

> I don't understand exactly what is going on with the integer stuff and
> wanted to push it your direction, but thought it prudent to see if you had
> the tools to deal with the problem first. As you could probably guess it
> is at a word boundary. It is triggered when calling a user defined
> function in a continuous assignment with 32 bit wide values on a 32 bit
> machine. If I change everything to 31 or 33 bit things not longer read
> invalid memory, but the 33 bit case appears to allocate more memory than
> needed. The compiled code looks to be correct in all cases.

Is there also a problem at exactly 64bits (on a 32bit system)? Integer
arithmetic converts logic to an array of longs to hold the bits that
are then used in the calculations. Could the problem be in that area?
User defined functions are processed by a vthread just like behavioral
code, so does a purely behavioral version have similar troubles?

If you post the example code you're working with I might be able to
help describe what's at least supposed to be happening.

> The example program is producing the correct results for my simple test,
> but could fail without warning for different input values. I can get back
> to this after I fix the real problems, but since you were just working in
> the user function code you could likely fix it faster.
> 
> Let me know what you would like me to do. I can provide more details and a
> patch with some fprintf/cerr statements to show what is going on at
> various points in the code.

I'm actually busy (when I'm not working on day job of course) reworking
the compiler handling of lexical scope so my head is full of a different
part of the code at the moment.

- --
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

iD8DBQFHteB1rPt1Sc2b3ikRAkhnAJ4jF+JV1oJP2qOO5GuT+9qGiAd3fwCbBe3x
rBiTl5ELRJX5bEGXQPIqHFI=
=JzVH
-----END PGP SIGNATURE-----

[Iverilog-devel] Compiling nested scopes

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

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


It looks like pr1887299 has pointed out a design flaw in how
scope hierarchy is managed at parse time. The problem there is
caused by a nested scope (a user defined function in this case)
being defined within a generate case. The Xilinx supplied code
defines a function within a generated case. Yuck!

So my next big task is going to be to rework how nested scopes
are handled at the pform level. This'll be a fairly big task
what will tough pform.cc and parse.y where nested scopes are
handled, as well as where the items put in those scopes (wires
et al) are handled.

So beware if you are working in any of those areas!
- --
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

iD8DBQFHscS/rPt1Sc2b3ikRAg5mAKDMwsUtH6XLcHqx5YGWz0BTGzSJ/QCgz50a
TXWHSQKyyH5zgBjof9vpkNQ=
=32HV
-----END PGP SIGNATURE-----

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-----

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

[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] Is therte something like a commit log

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

--- Uwe Bonnes <bo...@el...> wrote:

> I didn't know about gitk. Maybe the best way  for the user is to do a
> git
> pull and then gitk.

Yes gitk is your friend.

Cary


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

Re: [Iverilog-devel] patch activity

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

--- Stephen Williams <st...@ic...> wrote:

> So that graph seems to be saying that patch submission is somewhat
> bursty. And are we really past 50 patches this year?! That doesn't
> count the work I did, so that is significant.

That looks about right. The SourceForge tracker shows 70 over the last two
months. I'm probably a bit responsible for the burstiness of the graph. I
do much of my work over the weekend, but for a number of reasons usually
submit the patches on Monday or later as I have time to test them on my
Linux machine. I have also been trying to compartmentalize my patches
instead of submitting one big behemoth. This helps minimize the chance my
changes will collide with another.

Cary


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

Re: [Iverilog-devel] patch activity

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

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

Larry Doolittle wrote:
> For your amusement.
> 

I am indeed amused:-)

So that graph seems to be saying that patch submission is somewhat
bursty. And are we really past 50 patches this year?! That doesn't
count the work I did, so that is significant.

- --
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

iD8DBQFHqLGprPt1Sc2b3ikRAmuqAJ4sk3WbpGQENft46Kd0CQGIQFpDPACgya9d
2nFNcn9mOO6vBaD9jgsdInE=
=hzK/
-----END PGP SIGNATURE-----

[Iverilog-devel] patch activity

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

For your amusement.

   - Larry

Re: [Iverilog-devel] Is therte something like a commit log

[Uwe B. <bo...@el...>]

>>>>> "Stephen" == Stephen Williams <st...@ic...> writes:

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

    Stephen> Uwe Bonnes wrote:
    >> Dear Stephen,
    >> 
    >> is there any automativ way to get informed when someting changes in
    >> the git?  At the moment I do a "git pull" from time to time to see if
    >> anything happened.

    Stephen> I think you are actually looking for some sort of hooks in the
    Stephen> central repository that sent a message whenever the repository
    Stephen> is changed. Yes? Perhaps the way to do it would be to set up
    Stephen> the update hook to send a message to a mailing list set aside
    Stephen> for the purpose.

Well,

I didn't know about gitk. Maybe the best way  for the user is to do a git
pull and then gitk. 

The hooks may be another possibility, but there is nor urgent need after
knowing about gitk. There is a chance to drown in commit messages ...

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Iverilog-devel] Is therte something like a commit log

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

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

Uwe Bonnes wrote:
> Dear Stephen,
> 
> is there any automativ way to get informed when someting changes in the git?
> At the moment I do a "git pull" from time to time to see if anything
> happened.

I think you are actually looking for some sort of hooks in the
central repository that sent a message whenever the repository
is changed. Yes? Perhaps the way to do it would be to set up the
update hook to send a message to a mailing list set aside for
the purpose.

Any gut experts out there with the necessary experience?

- --
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

iD8DBQFHp1MQrPt1Sc2b3ikRAnRzAJ9tf+/c224N6nTYrj1iA1kQr+lA2ACgnvv3
tJS9+Wl2aQ7ey1Vgl2KT5Ao=
=KOMU
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Is therte something like a commit log

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

--- Uwe Bonnes <bo...@el...> wrote:

> is there any automativ way to get informed when someting changes in the
> git?
> At the moment I do a "git pull" from time to time to see if anything
> happened.

A git pull followed by gitk is the best we have to offer at the moment.

It would be nice to have a weekly/biweekly summary of git changes posted
to iverilog-announce. The problem is we need someone to set aside time to
do the summary. If there is a strong interest and no one else steps
forward I would be willing to do it, but it will likely impact my
bug/enhancement time.

I don't think the task is too complicated. Most of the git headers are
fairly self explanatory. The hardest part is probably recasting the
information into something that is more meaningful to a Verilog user.

So is anyone interested in taking this on and is this something people
would find useful?

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

[Iverilog-devel] Is therte something like a commit log

[Uwe B. <bo...@el...>]

Dear Stephen,

is there any automativ way to get informed when someting changes in the git?
At the moment I do a "git pull" from time to time to see if anything
happened.

Uwe
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Iverilog-devel] oddity in reproducing pr1879226

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

Steve -

On Wed, Jan 30, 2008 at 09:56:26AM -0800, Larry Doolittle wrote:
> Adding -Wextra (new name for -W) to C{,XX}FLAGS with
> gcc-4.3 yields, among other things, the following:

Adding a few more flags, I can get 1552 warnings of the form:
../verilog-0.9/elaborate.cc:121: warning: conversion to 'unsigned int' from 'long unsigned int' may alter its value
or
../../verilog-0.9/tgt-vvp/vvp_process.c:251: warning: conversion to 'unsigned int' from 'int' may change the sign of the result

    - Larry

Re: [Iverilog-devel] oddity in reproducing pr1879226

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

Steve -

On Wed, Jan 30, 2008 at 09:33:11AM -0800, Stephen Williams wrote:
> Of course there may be other int/long/signed/unsigned sloppynesses
> in there. The warnings used to be lingering reminders but we seem
> to be rid of those warnings

I can fix that!  Adding -Wextra (new name for -W) to C{,XX}FLAGS with
gcc-4.3 yields, among other things, the following:

../../verilog-0.9/vpi/sys_readmem.c:544: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/sys_sdf.c:73: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt_write.c:1032: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt_write.c:1917: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt_write.c:2598: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt2_write.c:1047: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt2_write.c:1090: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt2_write.c:1141: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt2_write.c:1150: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt2_write.c:1226: warning: comparison between signed and unsigned
../../verilog-0.9/vpi/lxt2_write.c:1359: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/draw_mux.c:74: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/draw_mux.c:81: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/draw_mux.c:89: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/draw_mux.c:93: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/draw_ufunc.c:139: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/eval_expr.c:750: warning: comparison of unsigned expression >= 0 is always true
../../verilog-0.9/tgt-vvp/eval_expr.c:766: warning: comparison of unsigned expression >= 0 is always true
../../verilog-0.9/tgt-vvp/eval_expr.c:782: warning: comparison of unsigned expression >= 0 is always true
../../verilog-0.9/tgt-vvp/eval_expr.c:797: warning: comparison of unsigned expression >= 0 is always true
../../verilog-0.9/tgt-vvp/modpath.c:30: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:415: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:465: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:548: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:567: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:583: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:602: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:1252: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:1398: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:1418: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:1418: warning: comparison between signed and unsigned
../../verilog-0.9/tgt-vvp/vvp_scope.c:1426: warning: comparison between signed and unsigned

I looked at vvp_scope.c; those are a mix of assert()s and for loops.
Maybe innocuous.

   - Larry

Re: [Iverilog-devel] oddity in reproducing pr1879226

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

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

Larry Doolittle wrote:

> I detect sloppiness in the use of int vs. long.
> 
> The offending NetNet was created by the buggy shift elaborator
> with npins=0.  A NetNet's msb_ is initialized to npins-1, where npins
> is unsigned, and therefore npins-1 = 0xffffffff = 4294967295.  msb_ is
> declared long, so this result after cast is interpreted as 0x00000000ffffffff
> (4294967295) on a 64-bit machine, but 0xffffffff (-1) on a 32-bit machine.
> 
> Line 2151 of t-dll.cc is
>       obj->width_ = net->vector_width();
> where obj->width_ is declared unsigned (t-dll.h:576),
> but net->vector_width() is unsigned long (netlist.h:504).
> In the 64-bit case, the msb_ > lsb_ width calculation performed in
> vector_width() (netlist.cc:632) is 4294967295-0+1=4294967296,
> which yields 0 after the cast to unsigned.  In the 32-bit case,
> msb_ > lsb_ is false (-1 is not > 0), so the width calculation
> (netlist.cc:634) is 0-(-1)+1=2, cast to unsigned is still 2.

Looks like you nailed it. I've confirmed that the error does
happen on the mac (32bit) and your patch does indeed fix it. And
your analysis here explains the different behavior on a 64bit system.
So I'm confident the problem at hand is understood and fixed. Great!


> My new assert(npins>0) for NetNet will obviously help.  I'm not sure
> what other changes, if any, are called for.

Of course there may be other int/long/signed/unsigned sloppynesses
in there. The warnings used to be lingering reminders but we seem
to be rid of those warnings so we'll just have to keep an eye out
for them.

It is tricky that indices are signed as entered in the source code
(i.e. foo[4 : -1] but the widths of vectors are unsigned. It is also
true that in the canonical form, the form that vvp works in as opposed
to the index values passed to the user via vpi, they are unsigned and
zero based. This was done to simplify the code generator (all vectors
are zero-based with index-0 the LSB) but the signed indices are
preserved for presentation via the VPI. The signed indices to
canonical indices conversion is a place where the signed-unsigned-
32bit-64bit issues can get tangled, and that happens in the elaborator
and also in the vvp VPI interface. Something to watch out for.


- --
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

iD8DBQFHoLTXrPt1Sc2b3ikRAqLoAJ9TbfaMpy/GxzHfUs2YgCP1/7tPWgCg1xri
j5oFs1bRLo8NKEK1b0gx9hM=
=MlzI
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] oddity in reproducing pr1879226

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

On Tue, Jan 29, 2008 at 06:44:25PM -0800, Larry Doolittle wrote:
> Bet'cha nickel your tests passed on a 64-bit machine.  I attach the
> input file, and _different_ -t stub output file from two machines, one
> showing the error, the other not.  The command in both cases is simply
>    iverilog uwe.v -t stub
> The most meaningful difference between the two is 32 vs. 64 bitness.
> The iverilog in both cases is freshly compiled from current git, but
> with patch 1881942 disabled.

I detect sloppiness in the use of int vs. long.

The offending NetNet was created by the buggy shift elaborator
with npins=0.  A NetNet's msb_ is initialized to npins-1, where npins
is unsigned, and therefore npins-1 = 0xffffffff = 4294967295.  msb_ is
declared long, so this result after cast is interpreted as 0x00000000ffffffff
(4294967295) on a 64-bit machine, but 0xffffffff (-1) on a 32-bit machine.

Line 2151 of t-dll.cc is
      obj->width_ = net->vector_width();
where obj->width_ is declared unsigned (t-dll.h:576),
but net->vector_width() is unsigned long (netlist.h:504).
In the 64-bit case, the msb_ > lsb_ width calculation performed in
vector_width() (netlist.cc:632) is 4294967295-0+1=4294967296,
which yields 0 after the cast to unsigned.  In the 32-bit case,
msb_ > lsb_ is false (-1 is not > 0), so the width calculation
(netlist.cc:634) is 0-(-1)+1=2, cast to unsigned is still 2.

My new assert(npins>0) for NetNet will obviously help.  I'm not sure
what other changes, if any, are called for.

   - Larry

[Iverilog-devel] oddity in reproducing pr1879226

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

Comment By: Stephen Williams (stevewilliams) Date: 2008-01-29 18:14 re:
patch 1881942
> Um, I applied the patch, but that test passed BEFORE I applied the patch.
> For that matter, so did the test in the original submission. I'll run the
> test on my mac when it gets home from school, but for now I'll assume you
> really did replicate and repair the problem.

Bet'cha nickel your tests passed on a 64-bit machine.  I attach the
input file, and _different_ -t stub output file from two machines, one
showing the error, the other not.  The command in both cases is simply
   iverilog uwe.v -t stub
The most meaningful difference between the two is 32 vs. 64 bitness.
The iverilog in both cases is freshly compiled from current git, but
with patch 1881942 disabled.

64-bit machine is amd64, gcc-4.3, Debian Sid
32-bit machine is i386, gcc-4.1, Ubuntu Gutsy

I will investigate further.  If y'all find some other pattern as to
when the stub target finds an error on this code, let me know.

    - Larry