IIn the adlc, the ins_encode construct is used with instruction
encodings that must be defined in the encode section.  This creates
several problems for reading the code as the assembly and the instruct
definition are far apart and you often have to duplicate the enc_class
if the types are different.  We'd like to encourage the use of
MacroAssembler for both readability and maintenance reasons so we'd
like to sweeten the syntax for defining encodings.  The simplest
version is to allow encoding classes to be specified inline with the
arguments implicitly defined.  Additionally we automatically construct
a MacroAssembler instance for use by the assembly.

For instance, this instruction defininition:

instruct addI_reg_reg(iRegI dst, iRegI src1, iRegI src2) %{
  match(Set dst (AddI src1 src2));

  size(4);
  format %{ "ADD    $src1,$src2,$dst" %}
  ins_encode %{
    __ add($src1$$Register, $src2$$Register, $dst$$Register);
  %}
  ins_pipe(ialu_reg_reg);
%}

will expand to this emit function

  {
    // Define a MacroAssembler instance for use by the encoding.  The
    // name is chosen to match the __ idiom used for assembly in other
    // parts of hotspot and assumes the existence of the standard
    // #define __ _masm.
    MacroAssembler _masm(&cbuf);

    __ add(opnd_array(1)->as_Register(ra_,this,idx1), opnd_array(2)->as_Register(ra_,this,idx2), opnd_array(0)->as_Register(ra_,this));
  }

I modified a couple instruction in sparc.ad and i486.ad to illustrate
this usage and also fixed the define for __ to be consistent across
files and with the adlc.  Someday we should switch it all to work this
way but for now I wanted to make it available for new encodings.