Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

cord(1)								      cord(1)


  cord - Rearrange procedures in an executable file to facilitate better
  cache	mapping


  cord [-vV] [-o outfile] [-f] [-c cachesize] [-p maxphases] obj-file


  The cord command accepts the following options:

  -v  Prints verbose information. This includes	listing	those procedures that
      are considered part of other procedures and that cannot be rearranged
      (that is,	assembler procedures that may contain relative branches	to
      other procedures instead of relocatable branches). The listing also
      lists those procedures in	the flipped area (if any) and a	mapping	of
      old location to new.

  -V  Displays the version of the cord command.

  -o outfile
      Specifies	the output file. If not	specified, a.out is used.

  -f  Flips the	first cachepage	size procedures. When cord was written,	the
      assumption was that procedures would be reordered	by procedure density
      (cycles/byte). This option ensures that the densest part of each page
      following	the first cachepage would conflict with	the least-dense	part
      of the first cachepage.

  -c cachesize
      Specifies	the cache size (in bytes) of the machine on which you want to
      execute. This only affects the -f	option.	If not specified, 65536	is

  -p maxphases
      Specifies	the maximum number phases allowed. The default is 20.


  The cord command rearranges procedures in an executable object file to max-
  imize	efficiency in a	machine's cache. By rearranging	the procedures prop-
  erly,	you can	reduce the instruction cache miss rates. The cord command
  does not attempt to determine	the correct ordering; it must be given a
  reorder-file containing the desired procedure	order. The reorder file	is
  generated by the ftoc	program, which in turn generates a reorder file	from
  a set	of profile feedback files (see prof(1)).

  Processed lines in the reorder file are called procedure lines. Each pro-
  cedure line must be on a separate source line. Each procedure	line must
  contain the source name of the file, followed	by a blank, followed by	a
  qualified procedure name. Nested procedures must be qualified	x.y, where x
  is the outer procedure. A newline or blank can follow	the procedure name:

  foo.c	bar (everything	else following is ignored)

  Lines	beginning with # are comments, lines beginning with $ are considered
  cord directive lines.	The only directive currently understood	is $phase.
  This directive will consider the rest	of the file (until the end of file or
  next $phase) as a new	phase of the program and will order the	procedures
  accordingly.	A procedure may	appear in more than one	phase, resulting in
  more than one	copy of	it in the final	binary.	First, cord will try to	relo-
  cate procedure references to a copy of the procedure belonging to the
  requesting phase; otherwise, it will relocate	the references to a random

  Use the -cord	option to a compiler driver like cc(1) rather than execute
  cord directly. The cord options can be specified with
  -Wc,cordarg0,cordarg1,.... If	you have to run	cord by	hand, you may want to
  run it once with the driver using the	-v option on a simple program. This
  will enable you to see the exact passes and the arguments involved in	using


       Since cord works	from an	input list of procedures generated from	pro-
       file output, the	resulting binary is data dependent. In other words,
       it may only perform well	on the same input data that generated the
       profile information, and	may perform worse than the original binary on
       other data. Furthermore,	if the hot areas in the	cache do not fit well
       into one	cachepage, performance can degrade.


  Commands:  cc(1), ftoc(1), ld(1), prof(1)

  Programmer's Guide