PL/I LANGUAGE CONVENTIONS

     This  section  highlights  the  coding rules for system  programs that are to be
written in the PL/I language.    Recommendations for  generating  efficient  code are
included.    The rules are to be taken   as guidelines   there will be  rare programs
that follow every rule.   Refer to "Efficient PL/I Constructs" below.

     PL/I  is  the  Multics Operating  System  programming language.  However,  there
are several features in the language which  should be  avoided  either  because  they
are  inefficient,  they are not  implemented  well  by our compiler,  or they lead to
complex  coding constructs.   The following language features  should be  avoided  by
subsystem programs:

     1.     use of PL/I input/output statements

     2.     aggregate expressions (except for assignment)

     3.     condition prefixes

     4.     use of "returns (char (*))"

     5.     use of the built-in function decat


     The following list describes some general restrictions and requirements

     1.     all variable names have to be declared in a declare statement

     2.     each  reference to a  member  of  a structure  must be qualified   by the
            name of the level-one containing structure

     3.     no compilation warning messages or error messages are allowed

     4.     implicit conversions should not be used

     5.     multiple block closures by an end statement should not be used

     6.     the default statement should not be used

     7.     executable  statements should be used to  initialize  automatic variables
            to make the action more explicit,  rather than the initial attribute.

     8.     no variable names should be the same as keywords in the PL/I language.


     This  subsection  is an  informal  guide to  efficient use of  the  Multics PL/I
compiler.   It provides   advice  on how to  take advantage of  the  good features of
the compiler  while avoiding its   weaknesses.   Emphasis is   placed  on  constructs
which   produce more   efficient code   than others.    The reader   is assumed to be
familiar with PL/I.

     For  a  semiformal  definition  of the  language  supported by the  Muitics PL/I
compiler, see the Multics PL/I Language Specification,  Order No. AG94.

The Alignment Attributes

     The  use of the  aligned  attribute and  the  unaligned  attribute  can  have  a
great effect on the  speed of a  program and the  size of its  data base.   Unaligned
items   can start on   a bit boundary   (character boundary  for   character strings,
pictures,  and   decimal  variables),   aligned   items   must   start  on at least a
fullword  boundary and  occupy an   integral   number   of fullwords.    If a   value
requires 72 bits or  less of  storage to  represent it,  access of the  value will be
faster if its generation of  storage is  aligned because  it can be  directly  loaded
into the aq registers.


     Access  of  aligned  binary and  pointer  variables is  usually faster than that
of   unaligned variables.    The only   exception to   the above   is that  unaligned
pointers  that   the   compiler   recognizes  as  aligned   are  accessed   at speeds
comparable   to that   of aligned   pointers, but   the former   cannot be indirected
through.   You  should  use aligned  binary and pointer  variables   for local scalar
variables,   and  only use   unaligned binary and   pointer variables in   large data
structures where size is important, but speed of access is not.

     The alignment   attribute   has  no   effect   on   the   access time of decimal
variables or varying strings.


     A  short  string is  defined to be a  nonvarying  string with  constant  extents
whose  length   is less than   or equal to   72 bits (eight  characters).   Access of
aligned  short strings   is usually  much   faster   than that   of unaligned   short
strings.   Thus,  it   is recommended that one use  aligned   short strings for local
scalar variables,  and restrict the use  of  unaligned  short  strings to  large data
structures where space is important.


     All  nonvarying strings   that are   not   short   are considered   to be  long.
Because  these strings are too  long to   fit into the aq  registers or  their length
is not known at compile time,  the use of the  aligned  attribute  does not  speed up
their   access.   It   is   recommended   that   one   use   the   default  alignment


     For  the  purposes  of this  discussion,  short  variables are  those  variables
which  occupy no more than 72 bits  (eight characters) of  storage  and are  declared
with constant extents.

     When  accessing an  element of  an  array of  short  unaligned  variables,   the
access  code  is  quicker if  a  constant  subscript  is used,  because  the compiler
uses an   EIS (Extended Instruction Set)   instruction,  when the  subscript   is not
constant,   in   accessing   the  variable.    If  an  unaligned  short  variable  is
contained in an    array  of  structures, and  the variable    is  accessed   with  a
nonconstant  subscript,  access   code is faster if the  array  is declared  aligned,
because the use of an EIS instruction is avoided.

Use of the Precision Attribute in Offset and Length Expressions

     Because  the Multics  CPU's  index   registers   can   only   hold   18  bits of
information, while up to  24 bits may be  needed to  express  the  offset  or  length
of a  string  for  use in  an EIS instruction,  the  compiler  must  make use  of the
precision   attribute   in  deciding   which  register  to  use.    If  a   subscript
expression, the second or third argument  of the  substr  builtin,   or the  declared
length of  a string  has a  precision  of 18 or  less,  it can  be  kept in  an index
register, whereas if the precision is more  than   18, it  must be  kept in  the a or
q  register.   This  means,  for  example,  that  if a  user  knows  that  he wants a
substring that  may be  more than  262,143  items long,  then  the  precision  of the
third  argument  of substr  should  reflect  that fact (otherwise the high-order bits
of the length may be lost).   Conversely,  if the user knows  that a  string  is less
than  262,144  items long,  he should  reflect  that knowledge in the  precision used
for subscripts  and  arguments to  substr.    (Besides  looking at the   precision of
the  length and  offset  expressions,  the compiler also  makes  use  of the declared
string size in cases of  constant  extents to  determine  where  the offset or length
may be kept.)

     The  general  guideline  is  to  always   declare  variables  with  the  correct
precision.   The  following  precisions  are  guidelines  when  a user is  not sure a
smaller precision will suffice.   A word offset  into a  segment  should be  declared
fixed bin(18).   A number of words  on a  segment  should be  declared fixed bin(19).
Character   string  indexes  and lengths  should  be  declared  fixed  bin(21).   Bit
string indexes and lengths should be declared fixed bin(24)

The Use of Internal Static to Simulate Named Constants

     If a  variable is  declared to be  internal  static  with an  initial  attribute
and  is  never  set  within a  program,  the  compiler will treat it as  if it were a
constant.   (A  variable is considered set if  it appears  on  the  left  side  of an
assignment statement,  is the first argument  of a  pseudovariable,   or a  reference
of a  defined attribute.)   Converting  an   internal static  variable to  a constant
means  that  more  efficient  code  will  often  be  generated  to  use the variable,
sometimes avoiding storage references, and that the variable  will  not  have  to  be
copied  into the  combined  linkage  section  upon initiation of the segment.   Since
passing a variable as an  argument is  equivalent to  setting it,  one  must  enclose
the  variable  in parentheses  if it is to  appear  in an  argument list.   This will
make the variable be  passed by value and  force a  copy to  be  made at  call  time.
The  options(constant)  attribute  may  be  used   to  tell  the  compiler  that  the
variable is  not set even if  passed as an  argument.    Making  sure  that  such  an
internal   static  variable,  which  the  user  intends  to  use  as a  constant,  is
considered by the compiler to be a  constant is  worthwhile  if the  variable is  not
a  long  string  which  is  only  used in a few calls.  This  feature of the compiler
is a good substitute for named  constants  which the  PL/I  language  generally  does
not provide.

     When  "options(constant)"   is  added to  the  declaration of an internal static
initialed  variable,  the variable is  allocated in the  text section  whether or not
it  is set or   passed as an argument.   The user is   responsible  for ensuring that
the variable is   not actually set,  however,  as  this would   cause faults or other

Use of the Initial Attribute

     The  compiler's  implementation   of   the   initial   attribute  for automatic,
based, and controlled arrays  is  inefficient   compared  with the code  the user can
get  from  explicit  assignment  statements.   Therefore, using the initial attribute
in the above cases is discouraged.   Since   the use of the  initial  attribute  does
not generate   code for  static  variables,   the above statement does   not apply in
that case.    Users are warned,   however,  that use   of the initial   attribute can
make a  program more  difficult to read   in some cases,  and that  initialization of
large   external static   arrays this   way can   cause creation   of a larger object
segment than intended.

The Assignment Operation


     In  deciding  whether or  not to use a  multiple  assignment   statement  rather
than    separate   assignment   statements,   is   useful   to   know   under   which
circumstances  multiple   assignment   statements  produce   inefflcient   code.    A
multiple assignment statement of the form;

     Ti, T2, ---, Tn = E;

where    E   is  not a   constant,    is  semantically   equivalent  to the  separate

     V  = E;

     T1 = V;

     T2 = V;




     Tn = V;

If the  temporary   represented by V  can be kept in   a machine  register throughout
the assignment,   then the multiple assignment  statement   is  efficient.   Clearly,
this  implies that    if E  is longer   than two    words,  the  multiple  assignment
statement  will not  be efficient,   since   E  cannot fit   in a   register.   Thus,
multiple  assignment  statements   are not  efficient when the right   hand side is a
long string, a varying string, an entry   value,  a  label value,  a   file value,  a
format value, an area, a decimal value, a complex value, or an aggregate.


     All of  the PL/I  conversions  are  efficient,   many of them  producing  inline
code,  while the  others  produce  calls  to  any_to_any_.   Inline  code is produced
for  all  cases   where  neither  the  source  nor   target  are  complex,   decimal,
character string,  or  picture  (see  the  discussion  of  pictures  below).   Of the
other cases, the following produces inline code:

     complex_float binary     (precision<=27) = real binary;

     real binary                    =     complex_float binary (precision<=27);

     real decimal                   =     real decimal;

     complex decimal                =     complex decimal;

     real binary integer            =     real decimal;

     real decimal                   =     real binary integer;

     character                      =     real fixed decimal;

     character                      =     real binary integer;

All other cases produce calls to any_to_any_.

     The  convert  builtin  function  can  be  used  to   effect  conversion  between
character  and  binary  and to  avoid  intermediate conversions  that other  builtins
might cause.


     The  use of  pictures  provides a  convenient way to  get  efficient  controlled
conversion  between  arithmetlc  and character.   When using pictures,  the  user can
avoid PL/I's inconvenient conversion rules by specifying the desired format.

     While  picture  unpacking  (going  from  character to arithmetic  form)  is done
by   pl1_operators,   the  most  common  cases  of   picture  editing   (going   from
arithmetic to  character form)  are done  inline.   Inline  code is generated for the
majority  of  cases  of  editing  into real fixed  pictures.   The cases  of  editing
into  real  fixed  pictures  that   is   done  by  pl1_operators_   are  any  of  the

     °     the absolute value of the number's scale is greater than 31

     °     a "y" picture character  appears  in  a  drifting  field  picture   (e.g.,

     °     a  zero  suppression  character  or  drifting  character  appears  to  the
           right of the "v" picture character

     °     the  inline  sequence  requires  more  than  63  micro-ops  for  the  MVNE


     Most  arithmetic  operations are  implemented  with fast inline  code.   The one
general   exception   is  the  power   operator  (e.g.   **)   which   is   sometimes
implemented  by pl1_operators_   or subroutine   calls,   users are cautioned against
using the "/"  operator with fixed point operands  as the  PL/I  precision  rules may
cause unexpected results.   Use the divide builtin function instead.


     Most   binary  arithmetic  operations  produce inline  code.   Multiplication of
fixed   binary    (precision>=36)  numbers  utilizes  pl1_operators_  references, all
fixed  binary   division   invoked  by   the   "/"    operator   causes    references
pl1_operators_ routines.

     The  "**"  operation  generates  pl1_operators_   calls for   real  operands and
full subroutine calls for  complex operands.    If the  operands  are both real,  and
the  second  operand is a  positive  integer  constant that could be represented as a
fixed bin(35)  value,  inline code will be   generated to do the  power  operation as
repeated multiplications.


     Most   decimal  arithmetic  operations   cause   efficient   inline   code to be
generated.    The major  exception is   the case   of one   or both   of the operands
having a   scale  greater than 32   or less than -31.    This case will often   cause
additional   assignments   or  multiplications  to   be  generated   since   the 6180
hardware only handles scales within the range -31  to 32.

     If  the power  operator  has  decimal operands,  a conversion to and from binary
and/or a subroutine call will be generated.

String Operations

     All  string  operations  (as opposed   to builtins)   cause inline   code  to be
generated.   In addition,   some  special  cases cause better than  usual code to  be


     Concatenation  is  often  used in   constructing varying   strings.   A   normal
concatenation of the form:

     a = b || c;

results in  three (3) moves -- b and c are moved  into a temporary,   and the  result
is moved into a.     However, a concatenation of the form:

     vs = vs || c;

where  vs is a  varying string,  results in just   one move --  a is moved to the end
of  vs.   The   latter special   case can   be used   to great  advantage in building
varying strings.   Consider the following example:

     vs =   a ||  b ||  c;

results   in  four moves   and perhaps some   instructions to allocate   temporaries,

     vs = a;

     vs = vs || b;

     vs = vs || c;

results in three moves with no temporaries allocated.


Most statements of the form:

          a = b <bool_op> c;

          a = translate (b,...);

          a = bool (b,c,<bolr>);

where  a,  b,  and   c are long nonvarying strings, cause code   to be generated that
performs   the  operation   in  a  temporary   and   then  moves   the result into a.
However,   if a is the same length as   the temporary  would be,  and if the compiler
believes that a  could not  possibly overlap   with b or c,   then the operation will
be performed directly in a and no temporary will be allocated.

     in a statement of the form:

     if a <op> b ...


     if bool (a, b, <bolr>) ...

where a   and b are long strings,   the  compiler will  attempt to   do the operation
without allocating  a  temporary,   by using an  SZTL instruction if the value is not
needed elsewhere.


     Most  aggregate  operations,   other than  simple  assignment and the use of the
string and   unspec builtins and   pseudovarlables,  are  relatively   inefficient in
the   present Multics   PL/I implementation    and should   be avoided.    By simple,
assignment, we mean assignment statements of the form:

     p -> aggregate = q -> aggregate;

Use of the Builtin Functions

     Most  of the  standard   PL/I   builtin   functions   and   pseudovariables  are
implemented  efficiently  in the  Multics  compiler.   However,  there are exceptions
and special cases.


     With the  exception  of the  divide builtin,   all the arithmetic builtins cause
effIcient code to be generated.   The  divide builtin is  inefficient  only for  some
cases in which a   fixed binary  result is  produced.   If a   fixed binary result is
produced,  a reference to a very   slow pl1_operators_  divide  routine is  generated
uniess the result   and both operands are unscaled with a  precision     less than or
equal to 35.


     Efficient  inline or  out-of-line  code is  generated  for all  but  one  string
builtin, decat.    Execution of the decat   builtin is  about 50   times  slower than
might be expected.

     There are  special  cases of  some of the   other  string  builtins   that cause
more  efficient code   to be generated  than is normally   generated for the  general
case.   These are:

     index (<char_str>, <char1>)

     index (<char_str>, <char2>)

     index (reverse(<char_str>), <char1>)

     index (reverse(<char_str>), <char2>)

     index (reverse(<char str>), reverse(<char2>))

     search (<char1>, <char_str>)

     verify (<char2>, <char_str>)

     search (<char_str>, <constant>)

     verify (<char_str>, <constant>)

     search (reverse(<char_str>), <constant>)

     verify (reverse(<char_str>), <constant>)

     translate (<char_str>, <constant> [,<constant>])

     before (<char_str>, <char1>)

     before (<char_str>, <char2>)

     after (<char_str>, <char1>)

     after (<char_str>, <char2>)

     ltrim (<char_str>, <constant>)

     rtrim (<char_str>, <constant>)

     copy (<char1_constant>, expression)


      References to  the mathematical  builtin  functions are  compiled  either  into
fast references  to  pl1_operators_   or   into   slower   subroutine   calls.    The
following  math  builtlns  are  implemented  in  pl1_operators_  if  they  have  real

     atan     exp      sin    tand

     atand    log      sind

     cos      log10    sqrt

     cosd     log2     tan

All other cases produce subroutine calls.

The Call Statement and Function References

     When a  call statement or  function  reference  is  executed,   in  the  general
case,  an  argument list  must be  constructed  which takes 3 + 2*number_of_arguments
words.    When the  new  procedure  block   is  entered,   a   new  stack   frame  is
established by a pl1_operators_  routine that  takes  around 30  instructions.   This
is  a high  overhead  to  have  when  using  an  important  feature  of  PL/I that is
necessary  for good  programming practice.   The Multics  system  PL/I  compiler  has
two  optimizations  which can  greatly reduce this overhead.   First,  it can  decide
that an  internal  procedure  or begin  block may  share the  stack frame of  another
block rather than  obtaining its own.   A block  that does not  obtain its own  stack
frame is  called  a  "quick"  block or  procedure.   Second,  the compiler  can build
argument  lists  to  quick  procedures  at  compile  time,   if  the  arguments  have
constant  addresses   known  at  compile  time.    These  two  optimizations  greatly
reduce the cost of call statements and function references.


     The  Multics PL/I  compiler goes  through  a  two  stage  process  to  determine
which  (procecure  or begin)  blocks  can be  quick,  that is,  which  ones need  not
obtain  stack frames.   The first stage  excludes  blocks  from  being quick  because
of their properties.   The following properties can make a block non-quick.

     °     it is the external procedure block

     °     it is an ON-unit

     °     it has I/O statements

     °     it has format staternents

     °     it has ON, or revert statements

     °     it has automatic variables with expression extents

     °     it  has an  entry  that is  assigned to an entry  variable or passed as an

     °     it has an entry with a star-extent return value

     °     it has an  entry with a  star-extent  parameter  that is  called  with the
           corresponding   argument    being   an    expression   whose   length   is

     °     it  has an  entry  that is  referenced in the argument list of such a call
           after the aforementioned argument

     In the second stage,  the compiler  uses a graph of the  calls  between  blocks,
to  determine  which of the remaining eligible blocks can be quick.    The  algorithm
used  in  this  stage is an  iterative  one  based  on  the  constraint  that a quick
block may use  the  stack frame of one  and only one non-quick  block and    thus may
effectively  be invoked  from only  one  non-quick  block.   In fact,  the  algorithm
states  that a  quick  block  may  be  invoked  from  only  one  stack frame,  and an
invocation from a quick block is considered an invocation from its      owner's stack

     A  user can determine which  blocks  have  been  made  quick  by  examining  the
symbols  listing  produced  by  the  compiler.    In  the  section  marked,  "STORAGE
REQUIREMENTS FOR THIS PROGRAM"  is a  list of all the      blocks in the program.  If
the  line  for a  particular  block  contains  the  words,  "shares stack frame  of",
that block is quick.


     In  generating  a quick  procedure  call,  the Multics  PL/I compiler  can often
generate a constant argument list if the  addresses  of the  arguments  are  known at
compile  time.    This  saves  the cost  of  executing  instructions  to  set up  the
argument  list  at  runtime.    At  this time   the  following  constraints  must  be
satisfied for the compiler to generate a constant argument list:

     °     the quick procedure must contain no non-quick blocks

     °     the stack frame of the caller must be smaller than 16,384 words

     °     the  arguments  must be  constants,  expressions  with operators,  builtin
           references,  function references, or automatic variables

     °     all  automatic  arguments must be allocated  in  the  stack  frame of  the

     °     all automatic arguments must have constant extents

     °     all subscripted arguments must have constant subscripts

Using If Statements

     In handling if statements containing logical operators, such as:

     if x = 0 | p ^= null | x + 3<z
          then call a;

     if z>3 & q = null & loaded
          then call b;

the  Multics  system  PL/I compiler  (as of  MR4.0)  attempts  to generate  code that
uses  the minimum number  of operations  to  decide the  result.   This is  a  change
from   previous  releases  of  the  compiler  that  always  evaluated  the   complete
expression in  the if statement.   In order  for  this optimization  to  take  place,
the user must  specify the -optimize control  argument for   the  compilation,  there
must be no irreducible  function references  in the  expression,  and the  expression
must  evaluate  to a bit(1)  value.   Thus a user  should  feel  free to use  logical
operators in if statements without worrying about their efficiency.

     NOTE:     no  program may depend on the  order of evaluation  of operands in the
     expression of an If statement.   Thus, the statement:

        if p ^= null
        & p -> q  = 0 then ...
        is illegal

Any  program  that  depends  on  complete  or    incomplete  evaluation  of  such  an
expression  is  in  error,   unless  the  expression  contains  irreducible  function
references,  in which case complete evaluation takes place.

Optimlzation of Comparisons

     The  Multics system  PL/I compiler (as  of  MR4.0)  remembers  in  its  abstract
machine state model the  most recent  comparison or  indicator  setting  operation at
any  particular  point  in time  in generating  object  code.    This  enables  it to
remove redundant comparisons  in constructs such as the following:

     if a<b
          then call foo;
          else if a = b
          then ...

Other Constructs That Are Costly or Dangerous

     °     default statements

     °     multidimensional arrays with star bounds

     °     arrays of elements of star extents

     °     programs requiring a stack frame of more than 16,384 words

This material is taken from:
Multics System Designers' Notebook(AN82-00)
Copyright Honeywell, Inc., 1980