Re: PATCH: add pa2.0 system instructions

Re: PATCH: add pa2.0 system instructions

[Jeffrey A Law]

  In message < 199906211343.JAA27277@wmtl249c.us.nortel.com >you write:
  > Changelog:
  > 
  > Mon Jun 21 09:42:05 EDT 1999  Jerry Quinn <jquinn@nortelnetworks.com>
  > 
  > 	* include/opcode/hppa.h (pa_opcodes):  Add entries for mfia
  > 	and mtsarcm instructions.
  > 
  > *** pa-prev/include/opcode/hppa.h	Sun Jun 20 23:51:34 1999
  > --- gas-src/include/opcode/hppa.h	Mon Jun 21 09:41:16 1999
  > ***************
  > *** 349,354 ****
  > --- 349,356 ----
  >   { "ldsid",      0x000010a0, 0xfc1f3fe0, "(b),t", pa10},
  >   { "mtsp",       0x00001820, 0xffe01fff, "x,S", pa10},
  >   { "mtctl",      0x00001840, 0xfc00ffff, "x,^", pa10},
  > + { "mtsarcm",    0x02c018c0, 0xffe0ffff, "x", pa20},
I believe this opcode is wrong. 

I believe the right opcode is 0x16018c0

Page 7-98 of the PA2.0 manual:
0x00 -- 6 bits
0x0b -- 5 bits
reg  -- 5 bits
res  -- 3 bits (must be zeros)
0xc6 -- 8 bits
0x00 -- 5 bits

Which looks like:
000000 01011 xxxxx 000 11000110 00000

Turn that into 4 bit nibbles for the opcode we get.
0000 0001 011x xxxx 0001 1000 1100 0000
 0    1    6    0    1    8    c    0


I believe the mask, operands, etc are correct

 
  > + { "mfia",	0x00001540, 0xffffffe0, "t", pa20},
Similarly I think your opcode is wrong with this one too.

Page 7-90 of the PA2.0 manual
0x00 6 bits
res  5 bits (must be zeros)
0x00 5 bits
res  3 bits
0xa5 8 bits
reg  5 bits

Which gives us:
000000 00000 00000 000 10100101 00000

Into 4 bit nibbles:
0000 0000 0000 0000 0001 0100 1010 0000
 0    0    0    0    1    4    a    0

I'm pretty sure your mask, operands, etc are correct


Running those instructions through the HP assembler confirms my encodings
of those instructions:

    4 00000000 (016018C0)          mtsarcm %r0
    5 00000004 (000014A0)          mfia %r0


I've got a 95% functional PA2.0 assembler (and testsuite) that Cygnus will
be contributing to binutils after it's delivered to HP (June 30) & cleaned up
a little in July.  I don't know if that changes your plans for contributing
this kind of stuff.

I'm going to fix the opcodes in your patch and install it.
jeff

PATCH: add pa2.0 system instructions

[Jerry Quinn]

Changelog:

Mon Jun 21 09:42:05 EDT 1999  Jerry Quinn <jquinn@nortelnetworks.com>

	* include/opcode/hppa.h (pa_opcodes):  Add entries for mfia
	and mtsarcm instructions.

*** pa-prev/include/opcode/hppa.h	Sun Jun 20 23:51:34 1999
--- gas-src/include/opcode/hppa.h	Mon Jun 21 09:41:16 1999
***************
*** 349,354 ****
--- 349,356 ----
  { "ldsid",      0x000010a0, 0xfc1f3fe0, "(b),t", pa10},
  { "mtsp",       0x00001820, 0xffe01fff, "x,S", pa10},
  { "mtctl",      0x00001840, 0xfc00ffff, "x,^", pa10},
+ { "mtsarcm",    0x02c018c0, 0xffe0ffff, "x", pa20},
+ { "mfia",	0x00001540, 0xffffffe0, "t", pa20},
  { "mfsp",       0x000004a0, 0xffff1fe0, "S,t", pa10},
  { "mfctl",      0x000008a0, 0xfc1fffe0, "^,t", pa10},
  { "sync",       0x00000400, 0xffffffff, "", pa10},

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:

[Brain death on opcodes snipped]

 Jeff> I've got a 95% functional PA2.0 assembler (and testsuite) that Cygnus
 Jeff> will be contributing to binutils after it's delivered to HP (June 30) &
 Jeff> cleaned up a little in July.  I don't know if that changes your plans
 Jeff> for contributing this kind of stuff.

I mostly started playing to get in the extra opcodes for long displacement
float load/store but started to look at completing the pa2.0 support.  So I
added the easy (!) stuff first.

If you have pa2.0 already working, I suppose it's silly for me to keep adding
the stuff to the current incarnation.  Is there anything that would make sense 
here for me to keep playing with?

Jerry

Re: PATCH: add pa2.0 system instructions

[Jeffrey A Law]

  In message < 14209.5087.709459.591226@gargle.gargle.HOWL >you write:
  > I mostly started playing to get in the extra opcodes for long displacement
  > float load/store but started to look at completing the pa2.0 support.  So I
  > added the easy (!) stuff first.
Certainly the way to go.  I started with the easy stuff too ;-)  The load/store
support is some of the ugliest stuff in the new PA2.0 support.  I'm hoping you
did a cleaner job than I so that I can toss my code in favor of yours instead
of trying to rewrite mine.

  > If you have pa2.0 already working, I suppose it's silly for me to keep
  > adding the stuff to the current incarnation.  Is there anything that would
  > make sense  here for me to keep playing with?
PA2.0 is basically working, though some of the code I'm not particularly happy
with (especially the PA2.0 load/store support).  Though as I continue to work
on the PA64 stuff I'm finding some problems with the PA2.0 support.

My plan is to clean up and contribute the stuff I did (that you haven't
already done) starting in mid July.  At the same time my development focus
is shifting to PA64 support (which will in turn stress the PA2.0 support).

I'll also be contributing gcc changes to support the new assembler syntax, so
there's no need to work on that, except from a testing standpoint.

There's still a variety of code generation issues that you may want to work
on.  For example finding more ways to make use of PA2.0 instructions, more
scheduling/code generation improvements, etc etc.  Having you look into this
stuff has been a great boon to the PA port.

jeff

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

>> "jeff" == Jeffrey A Law <law@cygnus.com> writes:

 jeff>   In message < 14209.5087.709459.591226@gargle.gargle.HOWL >you write:
 >> I mostly started playing to get in the extra opcodes for long displacement
 >> float load/store but started to look at completing the pa2.0 support.  So
 >> I added the easy (!) stuff first.
 jeff> Certainly the way to go.  I started with the easy stuff too ;-) The
 jeff> load/store support is some of the ugliest stuff in the new PA2.0
 jeff> support.  I'm hoping you did a cleaner job than I so that I can toss my
 jeff> code in favor of yours instead of trying to rewrite mine.

I only have a bit of it already implemented, mostly because I wasn't sure
about the best way to proceed in terms of codes.  But I'm willing to keep
working on it :-)

One thing I think will make things easier is the float code renaming I had
originally tried to submit.  I tried to count up the cases where we would need 
new codes and I don't think there are enough single letters left to do the job 
well.  Renaming the float codes will give us a significant amount of extra
room. 

The best situation would allow us to include some of the completers in the
opcode name itself, but I don't see how that will work easily.

 jeff> My plan is to clean up and contribute the stuff I did (that you haven't
 jeff> already done) starting in mid July.  At the same time my development
 jeff> focus is shifting to PA64 support (which will in turn stress the PA2.0
 jeff> support).

 jeff> I'll also be contributing gcc changes to support the new assembler
 jeff> syntax, so there's no need to work on that, except from a testing
 jeff> standpoint.

Are you making the new syntax active in gas at all levels or just 2.0?

 jeff> jeff

Jerry

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research

Re: PATCH: add pa2.0 system instructions

[Jeffrey A Law]

  In message < 14211.50168.462241.720881@gargle.gargle.HOWL >you write:
  > I tried to count up the cases where we would need 
  > new codes and I don't think there are enough single letters left to do the 
  > job well.  Renaming the float codes will give us a significant amount of
  >  extra room. 
There's a few ways to get more letters.

First, we're only using stuff in the printable ascii character set right
now.    It works perfectly well to use stuff like \001.  Which is the road
I started down.  However, it's not exactly great for readability.

Revisiting your prefixing stuff has been on my todo list for the cleanup.  The
one thing I don't like about it is it introduces more state into a pretty nasty
part of the assembler.  Then again, some of the PA2.0 support absolutely
requires state variables to hold information about the completers that's
needed later to know how to interpret certain operands.  Gross gross gross.

We also get a few back by dropping old-format disassembly.


  > The best situation would allow us to include some of the completers in the
  > opcode name itself, but I don't see how that will work easily.
I can be done -- I've done it for a wacky mips variant.  Basically you do
two table lookups.  First with the completer.  If there was no match, then you
do the lookup without the completer.

This kind of scheme works well if instructions have a single completer that
takes a small number of forms.  PA2.0 has some instructions which fall into
this category.

Putting completers into the opcode itself does poorly when opcodes have 
multiple
completers and/or the completers have many different forms.  That is the case
for most PA instructions.

  >  jeff> syntax, so there's no need to work on that, except from a testing
  >  jeff> standpoint.
  > 
  > Are you making the new syntax active in gas at all levels or just 2.0?
The assembler will accept either syntax.  The disassembler only disassembles
into the new style.

jeff

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

>> "jeff" == Jeffrey A Law <law@cygnus.com> writes:

 jeff>   In message < 14211.50168.462241.720881@gargle.gargle.HOWL >you write:
 >> I tried to count up the cases where we would need new codes and I don't
 >> think there are enough single letters left to do the job well.  Renaming
 >> the float codes will give us a significant amount of extra room.
 jeff> There's a few ways to get more letters.

 jeff> First, we're only using stuff in the printable ascii character set
 jeff> right now.  It works perfectly well to use stuff like \001.  Which is
 jeff> the road I started down.  However, it's not exactly great for
 jeff> readability.

Ick.

 jeff> Revisiting your prefixing stuff has been on my todo list for the
 jeff> cleanup.  The one thing I don't like about it is it introduces more
 jeff> state into a pretty nasty part of the assembler.  Then again, some of
 jeff> the PA2.0 support absolutely requires state variables to hold
 jeff> information about the completers that's needed later to know how to
 jeff> interpret certain operands.  Gross gross gross.

If I remember correctly, all the prefixing did was group all the float-related
codes into a second-level switch statement within a single case of the main
switch.  Which may or may not improve readability, since now all float-related
stuff is together.  I can't find that version of the patch now, so would have
to reconstruct it or dig it out of archives.  I didn't remember introducing
extra state variables when doing that.

I agree that the extra state stuff is a nuisance.  I've done some of the 64
bit conditional flag stuff by adding a flag that gets set and is detected
later.  


 >> The best situation would allow us to include some of the completers in the
 >> opcode name itself, but I don't see how that will work easily.
 jeff> I can be done -- I've done it for a wacky mips variant.  Basically you
 jeff> do two table lookups.  First with the completer.  If there was no
 jeff> match, then you do the lookup without the completer.

 jeff> This kind of scheme works well if instructions have a single completer
 jeff> that takes a small number of forms.  PA2.0 has some instructions which
 jeff> fall into this category.

 jeff> Putting completers into the opcode itself does poorly when opcodes have
 jeff> multiple completers and/or the completers have many different forms.
 jeff> That is the case for most PA instructions.

Ultimately, if we can free up enough codes to cover the new syntax, we
wouldn't have to play funky games with opcode names.

If you are willing to consider prefixing, we could also prefix the codes for
completers.  That would certainly free up enough codes to handle everything.

Jerry

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

>> "jeff" == Jeffrey A Law <law@cygnus.com> writes:

 jeff>   In message < 14209.5087.709459.591226@gargle.gargle.HOWL >you write:
 >> I mostly started playing to get in the extra opcodes for long displacement
 >> float load/store but started to look at completing the pa2.0 support.  So
 >> I added the easy (!) stuff first.
 jeff> Certainly the way to go.  I started with the easy stuff too ;-) The
 jeff> load/store support is some of the ugliest stuff in the new PA2.0
 jeff> support.  I'm hoping you did a cleaner job than I so that I can toss my
 jeff> code in favor of yours instead of trying to rewrite mine.

For what it's worth, if we can free up a bunch of codes I can get ldw
relatively clean (no extra state vars) using about 5 or 6 new codes.  How does 
yours work?

Jerry

Re: PATCH: add pa2.0 system instructions

[Jeffrey A Law]

  In message < 14213.7688.994516.981768@gargle.gargle.HOWL >you write:
  > For what it's worth, if we can free up a bunch of codes I can get ldw
  > relatively clean (no extra state vars) using about 5 or 6 new codes.  How
  > does yours work?

/* new syntax 32bit loads */
{ "ldw",        0x0c000080, 0xfc001fc0, "cx(s,b),t", pa10, FLAG_STRICT},
{ "ldw",        0x0c000080, 0xfc001fc0, "cx(b),t", pa10, FLAG_STRICT},
{ "ldw",        0x0c001080, 0xfc001fc0, "C5(s,b),t", pa10, FLAG_STRICT},
{ "ldw",        0x0c001080, 0xfc001fc0, "C5(b),t", pa10, FLAG_STRICT},
{ "ldw",        0x4c000000, 0xfc000000, "\017\020(s,b),x", pa10, FLAG_STRICT},
{ "ldw",        0x4c000000, 0xfc000000, "\017\020(b),x", pa10, FLAG_STRICT},
{ "ldw",        0x5c000004, 0xfc000006, "\017\021(s,b),x", pa20, FLAG_STRICT},
{ "ldw",        0x5c000004, 0xfc000006, "\017\021(b),x", pa20, FLAG_STRICT},

/* old syntax 32bit loads */
{ "ldw",        0x48000000, 0xfc000000, "j(s,b),x", pa10},
{ "ldw",        0x48000000, 0xfc000000, "j(b),x", pa10},

'c', 'C' and '\017' are potential completers.  

'x' only accepts a register of the for "%r<num" when in strict mode.

'5' is a short offset
'\020' and '\021' are long offsets

If the operand in the assembly file does not satisfy the letter, then we
"break" which indicates that the selected insn did not match.  Then we go on
to the next potential insn.

This is how most gas assemblers work (fail and try next insn).  The old PA
syntax did not lend itself to that kind of scheme.

It's important to realize that without some kind of stricter syntax checking
it is impossible to correctly parse something like this using the new syntax:

  ldw 5(0,4),9

That could be equivalent to either of these instructions (old syntax)

  ldwx %r5(%sr0,%r4),%r9	/* Indexed load */

  or

  ldw  5(%sr0,%r4),%r9  /* reg + d load */


In the old syntax, this case was disambiguated by using different opcodes, but
in the new case we have a single opcode.

jeff

Re: PATCH: add pa2.0 system instructions

[Jeffrey A Law]

  In message < 14213.4796.159208.605739@gargle.gargle.HOWL >you write:
  >  jeff> First, we're only using stuff in the printable ascii character set
  >  jeff> right now.  It works perfectly well to use stuff like \001.  Which i
  > s
  >  jeff> the road I started down.  However, it's not exactly great for
  >  jeff> readability.
  > 
  > Ick.
To put it mildly.


  > to reconstruct it or dig it out of archives.  I didn't remember introducing
  > extra state variables when doing that.
In that case, I must have mis-read the patch.


  > I agree that the extra state stuff is a nuisance.  I've done some of the 64
  > bit conditional flag stuff by adding a flag that gets set and is detected
  > later.  
Similarly.  Cleaning some of those up as best as I could is also on the
list of things I want to do before releasing that code.  I'm not happy with
the way that code works right now.

  > Ultimately, if we can free up enough codes to cover the new syntax, we
  > wouldn't have to play funky games with opcode names.
We need ~25 or so to make the assembler work.  Possibly few more for the
disassembler.

  > If you are willing to consider prefixing, we could also prefix the codes
  > for completers.  That would certainly free up enough codes to handle
  >  everything
I'm certainly willing to consider it.  I don't like using the non-ascii stuff.

jeff

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

law> 
law>   In message < 14213.7688.994516.981768@gargle.gargle.HOWL >you write:
law>   > For what it's worth, if we can free up a bunch of codes I can get ldw
law>   > relatively clean (no extra state vars) using about 5 or 6 new codes.  How
law>   > does yours work?
law> 
law> /* new syntax 32bit loads */
law> { "ldw",        0x0c000080, 0xfc001fc0, "cx(s,b),t", pa10, FLAG_STRICT},
law> { "ldw",        0x0c000080, 0xfc001fc0, "cx(b),t", pa10, FLAG_STRICT},
law> { "ldw",        0x0c001080, 0xfc001fc0, "C5(s,b),t", pa10, FLAG_STRICT},
law> { "ldw",        0x0c001080, 0xfc001fc0, "C5(b),t", pa10, FLAG_STRICT},
law> { "ldw",        0x4c000000, 0xfc000000, "\017\020(s,b),x", pa10, FLAG_STRICT},
law> { "ldw",        0x4c000000, 0xfc000000, "\017\020(b),x", pa10, FLAG_STRICT},
law> { "ldw",        0x5c000004, 0xfc000006, "\017\021(s,b),x", pa20, FLAG_STRICT},
law> { "ldw",        0x5c000004, 0xfc000006, "\017\021(b),x", pa20, FLAG_STRICT},
law> 
law> /* old syntax 32bit loads */
law> { "ldw",        0x48000000, 0xfc000000, "j(s,b),x", pa10},
law> { "ldw",        0x48000000, 0xfc000000, "j(b),x", pa10},

This looks similar to mine, except I used 'l' and 'L' for long offsets, and
'm' for the completer.  Also I didn't have a strict syntax flag.

law> It's important to realize that without some kind of stricter syntax checking
law> it is impossible to correctly parse something like this using the new syntax:
law> 
law>   ldw 5(0,4),9
law> 
law> That could be equivalent to either of these instructions (old syntax)
law> 
law>   ldwx %r5(%sr0,%r4),%r9	/* Indexed load */
law> 
law>   or
law> 
law>   ldw  5(%sr0,%r4),%r9  /* reg + d load */
law> 
law> 
law> In the old syntax, this case was disambiguated by using different opcodes, but
law> in the new case we have a single opcode.

Perhaps I don't understand here, but this doesn't seem ambiguous to me.  There
isn't ambiguity in the 0, 4, or 9.  In the old syntax, 5 can only be a
displacement.  In the new syntax, you have to use %r5 for a register, no?  The
HP assembler (rightly I think) decides that this must be a displacement, not
an index register.

As long as the code that grabs the 5 displacement doesn't also try to cast it
to a register, we should be fine.  However, so far, I've only made myself
really familiar with the main code processing loop, not the full extent of the
other number handling stuff, so I could be off base here.

Jerry

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

>> "jeff" == Jeffrey A Law <law@cygnus.com> writes:

 >> Ultimately, if we can free up enough codes to cover the new syntax, we
 >> wouldn't have to play funky games with opcode names.
 jeff> We need ~25 or so to make the assembler work.  Possibly few more for
 jeff> the disassembler.

 >> If you are willing to consider prefixing, we could also prefix the codes
 >> for completers.  That would certainly free up enough codes to handle
 >> everything
 jeff> I'm certainly willing to consider it.  I don't like using the non-ascii
 jeff> stuff.

In that case I'll work up a couple of prefixing patches to free up codes.  I
did a bit of counting and came up with the following categories and counts:

float register	      12
immediate values      18 (15 if we don't include branch displacements)
completers	      6
conditions	      13
spu and coproc	      7

I included the 64 bit condition flag, long displ load/store immediates and
completers in these counts.  Immediate values also include shift counts and
other such things.

I'd suggest we prefix the float regs and either conditions or immediate
values.  That should get us into the right territory.  It appears that a bunch 
of the new codes we need are completers, so if we prefix completers, that
would also be a big help.

Jerry

Re: PATCH: add pa2.0 system instructions

[Jeffrey A Law]

  In message < 14213.64155.863403.101617@gargle.gargle.HOWL >you write:
  > This looks similar to mine, except I used 'l' and 'L' for long offsets, and
  > 'm' for the completer.  Also I didn't have a strict syntax flag.
In mine, I'd used 'l' and 'L' for the FP loads/stores.  Note the integer and
FP long displacement loads & stores have to use different letters.


  > Perhaps I don't understand here, but this doesn't seem ambiguous to me. 
  > There isn't ambiguity in the 0, 4, or 9.  In the old syntax, 5 can only be
  > a displacement.
But the code which parses an 'x' operand (or any register operand) will accept
an immediate and treat it like a register number.  So, if you are using
existing letters to stand for registers, then you've got no way to distinguish
between those cases.  It's a serious issue.

Given the table fragment I posted, there's no way to get load-word with short
displacement without modifying how the 'x' and other register operands are
handled because 'x' will interpret the short displacement as a register #.

jeff

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

>> "jeff" == Jeffrey A Law <law@cygnus.com> writes:


 >> Perhaps I don't understand here, but this doesn't seem ambiguous to
 >> me. There isn't ambiguity in the 0, 4, or 9.  In the old syntax, 5 can
 >> only be a displacement.
 jeff> But the code which parses an 'x' operand (or any register operand) will
 jeff> accept an immediate and treat it like a register number.  So, if you
 jeff> are using existing letters to stand for registers, then you've got no
 jeff> way to distinguish between those cases.  It's a serious issue.

 jeff> Given the table fragment I posted, there's no way to get load-word with
 jeff> short displacement without modifying how the 'x' and other register
 jeff> operands are handled because 'x' will interpret the short displacement
 jeff> as a register #.

OK, I see.  Yeah that's a nuisance.  But, if we're willing to go to the effort
of prefixing to free up codes, we can handle this by adding codes that only
accept registers versus the ones that cast immediates to registers.  In this
case, the stricter syntax restriction comes for free.

Jerry 

Re: PATCH: add pa2.0 system instructions

[Jeffrey A Law]

  In message < 14214.11878.766249.924457@gargle.gargle.HOWL >you write:
  > But, if we're willing to go to the effort
  > of prefixing to free up codes, we can handle this by adding codes that only
  > accept registers versus the ones that cast immediates to registers.  In
  > this case, the stricter syntax restriction comes for free.
I think it's just as easy (or easier) to require % prefixing for registers
when dealing with new syntax.  That's how HP's assembler works and that's
basically what the FLAG_STRICT stuff does.  Anytime we're trying to match
an opcode using the new syntax we require all register operands to be prefixed
with %.

I've always hated the way HP allowed immediate values to be used in place of a
register or allowed you to simply omit operands (they would be silently
filled in as zero).  This kind of braindamage has led to numerous bugs in
hand-written assembly code over the years.

jeff

Re: PATCH: add pa2.0 system instructions

[Jerry Quinn]

>> "jeff" == Jeffrey A Law <law@cygnus.com> writes:

 jeff>   In message < 14214.11878.766249.924457@gargle.gargle.HOWL >you write:
 >> But, if we're willing to go to the effort of prefixing to free up codes,
 >> we can handle this by adding codes that only accept registers versus the
 >> ones that cast immediates to registers.  In this case, the stricter syntax
 >> restriction comes for free.
 jeff> I think it's just as easy (or easier) to require % prefixing for
 jeff> registers when dealing with new syntax.  That's how HP's assembler
 jeff> works and that's basically what the FLAG_STRICT stuff does.  Anytime
 jeff> we're trying to match an opcode using the new syntax we require all
 jeff> register operands to be prefixed with %.

Actually I was suggesting more or less the same thing except using codes
rather than a flag.  But I don't think it really matters which.

I've done a more complete accounting of the necessary codes and come up with
60(!), but I don't think there will be any preserved state in the main loops
this way.  Of these, 34 are completers, 8 shift amounts (most for new pseudos
shlw, shrd, shrw), 6 conditions, and 6 displacements.

I've posted a patch to group all the conditions to binutils.  That patch frees
up a number of codes.  I didn't have to do anything other than soak up a
character from the args.  

I think that additionally prefixing the completer and floating point register
codes will be enough to complete the 2.0 instruction set.

Jerry

PATCH: add pa2.0 system instructions

[Jerry Quinn]

Changelog:

Mon Jun 21 09:42:05 EDT 1999  Jerry Quinn <jquinn@nortelnetworks.com>

	* include/opcode/hppa.h (pa_opcodes):  Add entries for mfia
	and mtsarcm instructions.

*** pa-prev/include/opcode/hppa.h	Sun Jun 20 23:51:34 1999
--- gas-src/include/opcode/hppa.h	Mon Jun 21 09:41:16 1999
***************
*** 349,354 ****
--- 349,356 ----
  { "ldsid",      0x000010a0, 0xfc1f3fe0, "(b),t", pa10},
  { "mtsp",       0x00001820, 0xffe01fff, "x,S", pa10},
  { "mtctl",      0x00001840, 0xfc00ffff, "x,^", pa10},
+ { "mtsarcm",    0x02c018c0, 0xffe0ffff, "x", pa20},
+ { "mfia",	0x00001540, 0xffffffe0, "t", pa20},
  { "mfsp",       0x000004a0, 0xffff1fe0, "S,t", pa10},
  { "mfctl",      0x000008a0, 0xfc1fffe0, "^,t", pa10},
  { "sync",       0x00000400, 0xffffffff, "", pa10},

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research