Re: [Iverilog-devel] array element as index into array

[Martin W. <mai...@ma...>]

One big performance impact of switching to stack-based operands comes from the 
need to handle array accesses with undefined (x/z) indices. An existing 
example of this is in show_stmt_assign_sig_real(), where we have the code

             unsigned do_store = transient_id++;
             unsigned end_store = transient_id++;
             draw_eval_expr_into_integer(word_ex, word_ix);
             fprintf(vvp_out, "    %%jmp/0 t_%u, 4;\n", do_store);
             fprintf(vvp_out, "    %%pop/real 1;\n");
             fprintf(vvp_out, "    %%jmp t_%u;\n", end_store);
             fprintf(vvp_out, "t_%u ;\n", do_store);
             fprintf(vvp_out, "    %%store/reala v%p, %d;\n", var, word_ix);
             fprintf(vvp_out, "t_%u ;\n", end_store);

Obviously this will get even worse when there are both word and bit/part 
selects for a vector array.

One way to avoid this code bloat would be to have a flag associated with each 
index register to mark indices that were originally undefined values. With 
this, the array load/store instructions could handle the undefined indices 
case (they already have to deal with out-of-range indices, so this should not 
be a big change). With this, the above code could be collapsed to

             draw_eval_expr_into_integer(word_ex, word_ix);
             fprintf(vvp_out, "    %%store/reala v%p, %d;\n", var, word_ix);

Stephen Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I have a long term goal of turning the vvp thread into an entirely
> stack-backed engine. I've already done this with real and object
> types, and the change to the opcodes defined for i.e. real-valued
> expressions reflects this. (The most obvious impact is that the
> opcodes tend to take far fewer operands.)
>
> My thinking is that this will actually be a performance BOOST when
> I do this for bit vector operands, and will also make the opcodes
> like that discussed here much simpler.
>
> I very much want to get to this, but I have some pressing (read: paid)
> tasks in front of this.
>
> On 07/31/2013 02:36 PM, Martin Whitaker wrote:
>> Jared Casper wrote:
>>> I ran into a bug today where using an array element in an index
>>> or part select of an array element causes problems.  So something
>>> like this:
>>>
>>> a[1][idx[1]*4 +: 4] = 4'ha;
>>>
>>> where a is a reg array and idx is a reg or net array.  The
>>> problem is the %*/av instruction use static index registers as
>>> arguments (i.e. width is reg 0, base is reg 1, word address is
>>> reg 3).  So the vvp code, for example, sets register 3 with the
>>> word address, then evaluates the part offset expression into
>>> register 1, but in so doing clobbers register 3 if the part
>>> offset expression has an array access.
>> [snip]
>>> I was thinking I could just use allocate_word() to evaluate the
>>> expressions into temporary index registers, then move those into
>>> place before the %set/av or %assign/av call.  However, I couldn't
>>> see a way to move from one index register to another (am I
>>> missing something?)
>>>
>>> Thoughts on how to solve this?  Two options I see are to add a
>>> "%ix/mov <dst>, <src>" instruction and use the idea above, or to
>>> add arguments to the various %*/av instructions so that the
>>> register numbers for those arguments aren't static.
>>>
>> vvp instructions are currently limited to a maximum of three
>> operands, and the %*/av instructions already have three operands.
>> Although it wouldn't be too hard to raise this limit, it would
>> significantly increase the vvp runtime memory footprint, so this is
>> probably not a desirable option.
>>
>> Another option would be to turn the index register array into a
>> stack, but I'd be concerned about the performance impact of doing
>> this.
>>
>> Martin
>>
>> ------------------------------------------------------------------------------
>>
>>
> Get your SQL database under version control now!
>> Version control is standard for application code, but databases
>> havent caught up. So what steps can you take to put your SQL
>> databases under version control? Why should you start doing it?
>> Read more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>>
>>
> _______________________________________________
>> 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 v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlH5jMcACgkQrPt1Sc2b3ilG8ACeJ5Xq4VD3ojlQhOr2l9zwYClN
> TlEAn3X51V5P7xSLrx3jjzL4fYOn3bWL
> =qx6g
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>