defining 2-operand version of 3-operand insns?

defining 2-operand version of 3-operand insns?

[Greg McGary]

I want to define 2-operand versions of 3-operand ALU insns, like so:

	add	$s1, $s2	   ; 2-operand

which aliases:

	add	$s1, $s1, $s2

I can't find a way to copy $dest into $src1.
dni didn't like this encoding:
	(+ OP_ADDr dest (f-src1 dest) src2)

I tried dnmi, and it accepted this:
	(emit addr dest (f-src1 dest) src2)
and this:
	(emit addr dest (src1 dest) src2),
but not this:
	(emit addr dest dest src2),
but for the accepted cases, the src1 field assembled as 0, not as a copy of dest.

Clues?

Greg

Re: defining 2-operand version of 3-operand insns?

[Frank Ch. Eigler]

Hi -

On Fri, Dec 01, 2000 at 03:17:08PM -0700, Greg McGary wrote:
: I want to define 2-operand versions of 3-operand ALU insns, like so:
: 	add	$s1, $s2	   ; 2-operand
: which aliases:
: 	add	$s1, $s1, $s2

You can define these outside the alias mechanism, by the way.
Just provide two different insn objects.  If the parsing backtracking
code works correctly, then the right alternative should be chosen
automatically.


: [...]
: I tried dnmi, and it accepted this:
: 	(emit addr dest (f-src1 dest) src2)
: [...]

Have you tried
	(emit addr dest (f-src1 f-dest) src2)
instead?  OTOH, I've only seen (f-FIELD VALUE) construct used with
literal VALUE arguments.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6KCcWVZbdDOm/ZT0RApilAJ93n48c4Y+0RzWlojP6PE7dUZ6LIACfRAY7
K/NtK7dsSEhPgZWiJd4t/+s=
=z6wm
-----END PGP SIGNATURE-----

Re: defining 2-operand version of 3-operand insns?

[Greg McGary]

"Frank Ch. Eigler" <fche@redhat.com> writes:

> You can define these outside the alias mechanism, by the way.
> Just provide two different insn objects.

I thought I did that via `dni', but as stated before, cgen was
unhappy with the encoding.

> Have you tried
> 	(emit addr dest (f-src1 f-dest) src2)
> instead?

Yes.  CGEN accepts it, but there's no change in the output.

> OTOH, I've only seen (f-FIELD VALUE) construct used with
> literal VALUE arguments.

That appears to be the limitation.

I got this to work by employing a dirty trick.  Fortunately,
the dest and src1 operands are contiguous, so I defined a
new field that encompasses both, called f-dest2, and used
encode/decode magic to propagate:

(df  f-dest2   "dest dup'ed into src1"      () 25 10 UINT
     ((value pc) (add UWI value (sll UWI value (const 5))))
     ((value pc) (srl UWI value 5)))

The decode part is actually unused, since the insn that uses
dest2 has a NO-DIS attribute.

I used a similar dirty-trick to define a subtract immediate
pattern where only an `addi' instruction exists in the machine.
Alongside the normal 16-bit signed immediate field  f-simm16,
I defined f-nimm16 which is a negated version:

(df  f-nimm16  "negated 16-bit immediate"   () 15 16 INT
     ((value pc) (neg HI value))
     ((value pc) (neg HI value)))

Both of these work just the way I want.

Should we endorse or deprecate such abuses? 8^)

Greg

Re: defining 2-operand version of 3-operand insns?

[Greg McGary]

Greg McGary <greg@mcgary.org> writes:

> I got this to work by employing a dirty trick.  Fortunately,
> the dest and src1 operands are contiguous, so I defined a
> new field that encompasses both, called f-dest2, and used
> encode/decode magic to propagate:
> 
> (df  f-dest2   "dest dup'ed into src1"      () 25 10 UINT
>      ((value pc) (add UWI value (sll UWI value (const 5))))
>      ((value pc) (srl UWI value 5)))
> 
> The decode part is actually unused, since the insn that uses
> dest2 has a NO-DIS attribute.

Whereas this works for the assembler, it causes trouble for the
simulator:

Processing decoder for bits 31 30 29 28 27 26 ...
Filtering 2 instructions.
Instruction add2rambiguity-filtered by add3r
Instruction add3rambiguity-filtered by add2r
Processing decode entry 0 in decode_table_0, invalid ...

All of the instructions for which I have 2 & 3 operand versions
defined as above are excluded from the sim decoder as ambiguous.
Since the 2-operand versions are exclusively an assembler-language
convenience, they should be ignored from the simulator.
Unfortunately, I don't see a `NO-SIM' attribute.  Should I add one, or
is there a better way out of this jam?

Greg

Re: defining 2-operand version of 3-operand insns?

[Greg McGary]

Greg McGary <greg@mcgary.org> writes:

> Processing decoder for bits 31 30 29 28 27 26 ...
> Filtering 2 instructions.
> Instruction add2rambiguity-filtered by add3r
> Instruction add3rambiguity-filtered by add2r
> Processing decode entry 0 in decode_table_0, invalid ...

First, Here's a patch to add a space:

Index: insn.scm
===================================================================
RCS file: /usr/rback/release/tools-src/cygnus-unified/src/cgen/insn.scm,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 insn.scm
--- insn.scm	2000/12/05 17:50:18	1.1.1.1
+++ insn.scm	2000/12/06 18:34:40
@@ -729,7 +729,7 @@
 		 (keep? (not superset-insn)))
 	    (if (not keep?) 
 		(logit 2
-		       "Instruction " (obj:name insn) "ambiguity-filtered by "
+		       "Instruction " (obj:name insn) " ambiguity-filtered by "
 		       (obj:name superset-insn) "\n"))
 	    keep?))
 	insn-list)

> All of the instructions for which I have 2 & 3 operand versions
> defined as above are excluded from the sim decoder as ambiguous.
> Since the 2-operand versions are exclusively an assembler-language
> convenience, they should be ignored from the simulator.
> Unfortunately, I don't see a `NO-SIM' attribute.  Should I add one, or
> is there a better way out of this jam?

I have an idea.  filter-harmlessly-ambiguous-insns drops insns that
have fewer mask bits, retaining the most specific format.  A solution
to my problem would be to also compare number of operands and consider
the insn with more operands to be more specific.

Doug, does that sound reasonable to you, or are you philosophically
opposed to the entire 2/3 operand insn hack?

Greg

Re: defining 2-operand version of 3-operand insns?

[Doug Evans]

Greg McGary writes:
 > Doug, does that sound reasonable to you, or are you philosophically
 > opposed to the entire 2/3 operand insn hack?

Could I see the .cpu file in question so I have a clear understanding
of what the problems and issues are and so that I can play with them
myself?

[at this point I don't have enough info to form an opinion]

Re: defining 2-operand version of 3-operand insns?

[Frank Ch. Eigler]

Hi -

Greg McGary <greg@mcgary.org> wrote:
: > I got this to work by employing a dirty trick.  [...]
: > (df  f-dest2   "dest dup'ed into src1"      () 25 10 UINT
: >      ((value pc) (add UWI value (sll UWI value (const 5))))
: >      ((value pc) (srl UWI value 5)))
: > 
: > The decode part is actually unused, since the insn that uses
: > dest2 has a NO-DIS attribute.
: 
: Whereas this works for the assembler, it causes trouble for the
: simulator:
: [...]
: Since the 2-operand versions are exclusively an assembler-language
: convenience, they should be ignored from the simulator.
: Unfortunately, I don't see a `NO-SIM' attribute.  Should I add one, or
: is there a better way out of this jam?

I think there are two or three good longer term options:

* an extension to the insn macro code that would allow one to copy
  ifield values
* a generalization of insn ifield-assertions (the "(+ ENUM op (f-foo 1))"
  clauses) to permit specialization to override other alternatives, both
  for disassembly and for sim decoding

In the short term, another way would be to combine the two alternative
instructions into one, taking a special operand that stands for the
required/optional pair.  This operand would be associated with a parser
function in *.opc that consumes one or two comma-separated fields (depending
on the input string), and fills in the optional field in the former case.
(An associated printer routine can do the inverse transformation.)

Do I need to complete this sketch with an example?


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6Loh3VZbdDOm/ZT0RAgT3AJ9t7YCItTsKJoxXYQuDVcWSIKQv9wCfWIh8
mhqnUWtt61QLvlps/s3uN4g=
=5fdH
-----END PGP SIGNATURE-----

Re: defining 2-operand version of 3-operand insns?

[Doug Evans]

Greg McGary writes:
 > > OTOH, I've only seen (f-FIELD VALUE) construct used with
 > > literal VALUE arguments.
 > 
 > That appears to be the limitation.

I believe that's the case.  Supporting non-literal values
is a left-for-later extension.

 > I got this to work by employing a dirty trick.  Fortunately,
 > the dest and src1 operands are contiguous, so I defined a
 > new field that encompasses both, called f-dest2, and used
 > encode/decode magic to propagate:

Another way is to have assembler C code do the duplication.
Define a separate version of the operand used by the 2 operand
version and give it special parse/insert/extract/print handlers
(whatever's necessary - you might be able to get away with just a
special insert handler).

[in a later message]
 > All of the instructions for which I have 2 & 3 operand versions
 > defined as above are excluded from the sim decoder as ambiguous.
 > Since the 2-operand versions are exclusively an assembler-language
 > convenience, they should be ignored from the simulator.
 > Unfortunately, I don't see a `NO-SIM' attribute.  Should I add one, or
 > is there a better way out of this jam?

ALIAS is the NO-SIM attribute you're looking for.
Since this is an assembler side problem I'd prefer to keep it
out of the simulator too.  The ALIAS attribute will do that.

[in another message]
 > Doug, does that sound reasonable to you, or are you philosophically
 > opposed to the entire 2/3 operand insn hack?

I'm not at all opposed to this.  I support it!
[pedantic: as long as it's kept in the assembler side of things and
hacks aren't added to the simulator to support it]

Re: defining 2-operand version of 3-operand insns?

[Frank Ch. Eigler]

Hi -

On Wed, Dec 06, 2000 at 11:13:49AM -0800, Doug Evans wrote:
: [...]
: [in another message]
:  > Doug, does that sound reasonable to you, or are you philosophically
:  > opposed to the entire 2/3 operand insn hack?
: 
: I'm not at all opposed to this.  I support it!
: [pedantic: as long as it's kept in the assembler side of things and
: hacks aren't added to the simulator to support it]

On the other hand, consider that if the ifield-assertion code is
changed to allow reasonable generalization and specialization
alternatives, then this can be a simulator performance improvement
gadget.   It could subsume the (decode-splits*) construct that I
broke (disabled) a few months ago with the decoder revamping.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6LpLIVZbdDOm/ZT0RArCuAJ9rQy7fL+f5BARP1tCIOdN0UOpcVACfZS/k
nOhUYjjO39Q1l44qcmZNaec=
=CZnO
-----END PGP SIGNATURE-----

Re: defining 2-operand version of 3-operand insns?

[Doug Evans]

Frank Ch. Eigler writes:
 > Hi -
 > 
 > On Wed, Dec 06, 2000 at 11:13:49AM -0800, Doug Evans wrote:
 > : [...]
 > : [in another message]
 > :  > Doug, does that sound reasonable to you, or are you philosophically
 > :  > opposed to the entire 2/3 operand insn hack?
 > : 
 > : I'm not at all opposed to this.  I support it!
 > : [pedantic: as long as it's kept in the assembler side of things and
 > : hacks aren't added to the simulator to support it]
 > 
 > On the other hand, consider that if the ifield-assertion code is
 > changed to allow reasonable generalization and specialization
 > alternatives, then this can be a simulator performance improvement
 > gadget.   It could subsume the (decode-splits*) construct that I
 > broke (disabled) a few months ago with the decoder revamping.

That's an orthogonal issue.  There are lots of decoder games
one can play.  For example, on machines with few registers
one could have separate versions of relevant insns for each
possible input value (register, constant, whatever).  This
extends to machines with more registers and more operands (2 -> 3)
though there it gets unwieldy in the general case (with a smaller
machine (m68k, i386) you don't have to go to as much trouble
to keep the resulting number of versions of insns manageable).
But however one chooses to do this, it's orthogonal to
supporting shortcuts in assembler syntax.

Re: defining 2-operand version of 3-operand insns?

[Greg McGary]

Doug Evans <dje@transmeta.com> writes:

> ALIAS is the NO-SIM attribute you're looking for.
> Since this is an assembler side problem I'd prefer to keep it
> out of the simulator too.  The ALIAS attribute will do that.

Yes, ALIAS solves my problem.  Thanks!