iverilog-devel

[Iverilog-devel] Wondering aloud about extended operand lists

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

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


There are a handful of instructions in the vvp opcodes set that
are really pressed for operands. They are reduced to using implicit
index variables to carry operands that really can generally be
immediate.

So I'm wondering aloud if maybe it *is* time to extend the size
of the opcode space. In particular, I've been thinking of
adding to the second union a pointer to a vvp_code_extend_s
struct. This struct can be *much* more liberal, and can carry
more number values. This may wind up allowing us to replace
several hackish instructions with instructions with longer
operand lists.

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

iD8DBQFHiB7SrPt1Sc2b3ikRAoRyAJ496qz5lfZjWOiOEFKYJtbkAHhWRwCfX2O4
3qpvD9glHEqy106uhGwKev0=
=C0Yp
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Wondering aloud about extended operand lists

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

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

> There are a handful of instructions in the vvp opcodes set that
> are really pressed for operands. They are reduced to using implicit
> index variables to carry operands that really can generally be
> immediate.
> 
> So I'm wondering aloud if maybe it *is* time to extend the size
> of the opcode space. In particular, I've been thinking of
> adding to the second union a pointer to a vvp_code_extend_s
> struct. This struct can be *much* more liberal, and can carry
> more number values. This may wind up allowing us to replace
> several hackish instructions with instructions with longer
> operand lists.

Should this be done with the second argument or should it be collapsed
down to a single argument. Something like:

struct vvp_code_s {
  vvp_code_fun opcode; /* This determines the number/type of arguments. */

  union {
    some_inclusive_arg_type_union single_arg;
    some_inclusive_arg_type_union *array_of_args;
  }
}

There is probably a trade off somewhere based on the argument distribution
which may change as the opcodes are reviewed. Having a larger/arbitrary
number of arguments would allow us to build more complex opcodes that
should help performance (both speed and memory).

Cary


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

Re: [Iverilog-devel] Wondering aloud about extended operand lists

[Anthony J B. <net...@nc...>]

On Fri, 11 Jan 2008, Stephen Williams wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> There are a handful of instructions in the vvp opcodes set that
> are really pressed for operands. They are reduced to using implicit
> index variables to carry operands that really can generally be
> immediate.

It's been a while since I've read that vvp opcodes doc, however note the
following cut and paste typos in opcodes.txt:

| * %xor <dst>, <src>, <wid>
|
| This does a bitwise exclusive or (^) of the <src> and <dst> vector,
| and leaves the result in the <dst> vector. xor is this:
|
|        0 xnor 0 --> 0
|        0 xnor 1 --> 1
|        1 xnor 0 --> 1
|        1 xnor 1 --> 0
|        otherwise    x

-Tony

Re: [Iverilog-devel] Wondering aloud about extended operand lists

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

--- Anthony J Bybell <net...@nc...> wrote:
> It's been a while since I've read that vvp opcodes doc, however note the
> following cut and paste typos in opcodes.txt:
> 
> | * %xor <dst>, <src>, <wid>
> |
> | This does a bitwise exclusive or (^) of the <src> and <dst> vector,
> | and leaves the result in the <dst> vector. xor is this:
> |
> |        0 xnor 0 --> 0
> |        0 xnor 1 --> 1
> |        1 xnor 0 --> 1
> |        1 xnor 1 --> 0
> |        otherwise    x

Since I was already editing opcodes.txt I fixed these in a patch I am
submitting now.

Cary


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