How does one build and run cgen?

How does one regenerate the CGEN-related parts of a toolchain?

To-do items
I can't load "dev.scm" into guile
Does CGEN run on guile 1.6?
Using CGEN with cygwin
dni format description

CGEN is written in Scheme, and is usually run via a Scheme interpreter such as Guile. Therefore, no explicit configure/compile step is required for cgen itself.
Normally, the interpreted cgen sources, as well as files generated by cgen, all sit within in a common source tree that also includes the cgen-generated tools (the opcodes library and the various simulators). In a build tree configured from such a source tree, cgen rarely needs to be run: only when its inputs (.cpu/.opc description files, or .scm cgen sources) are changed. Even in such cases, cgen is rarely run by hand: instead, cgen is invoked via the make program in the generated tools directories.

See also:

    http://www.airs.com/ian/configure
    http://www.fsf.org/software/guile
    http://sources.redhat.com/fom/cgen?file=7

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Jakob Nielsen                 jakob.nielsen@dspfactory.com
  Senior DSP Engineer
  Dspfactory Ltd.                Tel: +1-519-884-9696 x252
  80 King Street S., Suite 206   Fax: +1-519-884-0228
  Waterloo, ONT, CANADA          http://www.dspfactory.com/
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

       $(SHELL) $(srcdir)/cgen.sh opcodes $(srcdir) $(CGEN) \
         $(CGENDIR) "$(CGENFLAGS)" $(arch) $(prefix) $(archfile) $(opcfile) \
         "$(options)" "$(extrafiles)"
         touch stamp-${prefix} 

From George Varughese:

If you want to run cgen scripts in a different directory other than
binutils/opcodes (GNU binutils),

copy binutils/opcodes/cgen.sh to the new directory, and create a makefile
(Makefile) as follows:

####### Makefile begin
srcdir=.
cgendir = ./cgen/src/cgen
CGEN = "guile -L $(cgendir) -l ${cgendir}/guile.scm -s"
# directory where all cgen .scm files are
CGENDIR = `pwd`/cgen/src/cgen
CGENFLAGS = -v
arch=tp01
prefix = tp01
archfile = `pwd`/tp01.cpu
opcfile = `pwd`/tp01.opc
extrafiles =
options =

# remember to use use tab where necessary
run-cgen:
       $(SHELL) $(srcdir)/cgen.sh opcodes $(srcdir) $(CGEN) \
         $(CGENDIR) "$(CGENFLAGS)" $(arch) $(prefix) $(archfile) $(opcfile) \
         "$(options)" "$(extrafiles)"
         touch stamp-${prefix}

###### Makefile end

and run make. This example assumes that your cgen inputs are tp01.cpu, and
tp01.opc.

Following text shows how cgen is called from binutils.
   
If you have gnu binutils downloaded and configured, cd to opcodes directory
run
   
make -n stamp-m32r
or
make stamp-m32r
   
to see how m32r related files  are generated using cgen.

opcodes directory contains a shell script "cgen.sh". If you insert
set -x
in this file, at the top, and run "make stamp-m32r", you will see how cgen guile
scripts are called.

When a target needs a change applied to its .cpu or .opc files, or cgen's
own .scm files, cgen must be rerun in order to propagate the changes to the
generated files elsewhere.

While some dependencies are recorded in the Makefiles, most or all are
approximate and incomplete (e.g., including only the .cpu file but not .opc;
including some .scm files of cgen itself but not all).  The safest way is to
regenerate cgen stuff by hand.  The problem is remembering what each build
directory's regeneration make target is:

opcodes:                         make stamp-TARGET
sim/TARGET:                      make stamp-arch stamp-cpu stamp-desc
sid/component/cgen-cpu/TARGET:   make cgen-all   

cgen puts the modified files back in the source tree.  When committing a
change to cgen inputs, one should commit the changes to regenerated files also.

Before you execute these 'make ...' commands your build tree
has to be built. Otherwise you'll get errors like:

make: *** No rule to make target `../cgen/stamp-cgen', needed by `stamp-vpe4k'.

Current CGEN bugs

Future enhancements:
dummy ER

   associated with the first encountered/described ISA is used.  This
   causes problems when ISAs of different base instruction size are
   defined in the same cpu file. 

   The base instruction size of the ISA associated with the instruction
   in question should be used.
   
   File: cgen/mach.scm
   Routine: state_base_insn_bitsize + feeder routines

2. When rereading a little endian instruction with a base instruction

   size of 16 bits plus a 16 bit immediate, the byte ordering gets
   hosed.  The problem occurs due to the 32 bits being interpreted as
   one little endian int not two 16 bit, little endian shorts.    

   File: opcodes/cgen-dis.in
   Routine: print_insn()

This error appears on both Solaris and Windows platforms.

  dev.scm:176:30: In procedure getenv in expression (getenv (quote HOME)):
  dev.scm:176:30: Wrong type argument in position 1 (expecting STRINGP): HOME
  ABORT: (wrong-type-arg) guile>

     ((PIPE OS) (IDOC ALU))
     "addx $dr,$sr"
     (+ OP1_0 OP2_9 dr sr)
     (parallel ()
               (set dr (addc dr sr condbit))
               (set condbit (add-cflag dr sr condbit)))
     ()

  ("0" "1" "2" "3" "4" "5" "6" "7"
   "8" "9" "10" "11" "12" "13" "14" "15")

  ("0" "1" "2" "3" "4" "5" "6" "7"
   "8" "9" "10" "11" "12" "13" "14" "15")