[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: Icarus Verilog 20010112 Snapshot
Hi Steve,
I have only one small patch left in my source tree, which fixes this
bug temporarily. But we may want to benefit from 64bit numbers in the
long term.
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.
Stephan
Index: tgt-vvp/eval_expr.c
===================================================================
RCS file: /home/demon/anoncvs/verilog/tgt-vvp/eval_expr.c,v
retrieving revision 1.54
diff -u -r1.54 eval_expr.c
--- tgt-vvp/eval_expr.c 2002/01/11 05:23:05 1.54
+++ tgt-vvp/eval_expr.c 2002/01/21 09:44:42
@@ -911,7 +911,7 @@
case IVL_EX_NUMBER: {
unsigned nbits = ivl_expr_width(ae);
const char*bits = ivl_expr_bits(ae);
- unsigned long v = 0;
+ unsigned v = 0;
unsigned idx;
for (idx = 0 ; idx < nbits ; idx += 1)
switch (bits[idx]) {
@@ -922,10 +922,10 @@
v |= 1 << idx;
break;
default:
- v = ~0UL;
+ v = ~0U;
break;
}
- fprintf(vvp_out, " %%ix/load 3, %lu;\n", (v-root)*width);
+ fprintf(vvp_out, " %%ix/load 3, %u;\n", (v-root)*width);
break;
}
case IVL_EX_ULONG: {
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;
>
--
Stephan Böttcher FAX: +49-4181-925676
Itzenbütteler Straße 130 Tel: +49-4181-32582
21266 Jesteburg mailto:stephan@nevis.columbia.edu
Germany http://www.nevis.columbia.edu/~stephan