Re: PATCH: add pa2.0 system instructions

["Jerry Quinn" <jquinn@nortelnetworks.com>]

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