as for the ESA/390 supports all of the standard ELF/SVR4
assembler directives that are documented in the main part of this
documentation.  Several additional directives are supported in order
to implement the ESA/390 addressing model.  The most important of these
are .using and .ltorg
   
These are the additional directives in as for the ESA/390:
     
.dc.drop regno.using directive in the
same section as the current section.
     .ebcdic string.string etc. emit
ascii strings by default.
     EQUas directive .equ can be used to the same effect.
     .ltorg.using must have been previously
specified in the same section.
     .using expr,regnoThis assembler allows two .using directives to be simultaneously
outstanding, one in the .text section, and one in another section
(typically, the .data section).  This feature allows
dynamically loaded objects to be implemented in a relatively
straightforward way.  A .using directive must always be specified
in the .text section; this will specify the base register that
will be used for branches in the .text section.  A second
.using may be specified in another section; this will specify
the base register that is used for non-label address literals. 
When a second .using is specified, then the subsequent
.ltorg must be put in the same section; otherwise an error will
result.
     
Thus, for example, the following code uses r3 to address branch
targets and r4 to address the literal pool, which has been written
to the .data section.  The is, the constants =A(some_routine),
=H'42' and =E'3.1416' will all appear in the .data
section.
     
          .data
          	.using  LITPOOL,r4
          .text
          	BASR	r3,0
          	.using	*,r3
                  B       START
          	.long	LITPOOL
          START:
          	L	r4,4(,r3)
          	L	r15,=A(some_routine)
          	LTR	r15,r15
          	BNE	LABEL
          	AH	r0,=H'42'
          LABEL:
          	ME	r6,=E'3.1416'
          .data
          LITPOOL:
          	.ltorg
     
     Note that this dual-.using directive semantics extends
and is not compatible with HLASM semantics.  Note that this assembler
directive does not support the full range of HLASM semantics.