Re: gEDA: Icarus Verilog 20010112 Snapshot

[Stephen Williams <steve-at-NOSPAMicarus_dot_com>]

stephan@nevis.columbia.edu said:
> The problem is: numbers in VVP code are all parsed as unsigned, but
> sometimes they represent negative values.  This is no problem, as long
> as the bit-size of the numbers is consistent.   

mcmahill@mtl.mit.edu writes:

> a few more data points.  I looked at the 'simv' file produced on each
> machine.  They're different:
> 
> --- /tmp/simv.alpha     Mon Jan 14 16:07:44 2002
> +++ simv.sparc  Mon Jan 14 15:57:06 2002
> @@ -105,5 +105,5 @@
>      %vpi_call "$display", "FAILED    m1=%b", V_pr303.m1;
>  T_0.2 ;
> -    %ix/load 3, 18446744073709551612;
> +    %ix/load 3, 4294967292;
>      %load/m  8, M_pr303.mem;
>      %ix/add 3, 1;
> @@ -130,5 +130,5 @@
>      %set V_pr303.e[2], 10;
>      %set V_pr303.e[3], 11;
> -    %ix/load 3, 18446744073709551612;
> +    %ix/load 3, 4294967292;
>      %load/m  8, M_pr303.mem;
>      %ix/add 3, 1;
> 

This has nothing to do with sign. The real problem here, now that I
look at it, is that there is apparently an 'x' or 'z' in a constant
memory address vector. What is supposed to happen in that case is the
memory is not indexed at all. The code generator, therefore, generates
a guaranteed bogus value, forcing an X result from the memory read.

It would be better to replace all of the the memory index expression
with a constant X result, and not even generate code to evaluate the
memory index expression.

No point in generating many lines of complex dynamic code to produce
simple constant values:-)
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
steve at picturel.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."