I have just started out to experiment with cgen.

I have instructions which are 16 and 32 bits long.
The assembler generates the right instructions with
the right lengths.

However when I do a dissassembly with objdump -D I get
only the first 16 bits decoded for 32 bit instructions
and (in my very very simple test case) *unknown* when it
tries to decode the second 16 bits of the 32 bit 
instruction.

If I change 

static int
extract_insn_normal (cd, insn, ex_info, insn_value, fields, pc)

in the generated dw32-ibld.c file to always return 32 bits,

ie. 
  return 32;
instead of the generated

  /* We recognized and successfully extracted this insn.  */
  return CGEN_INSN_BITSIZE (insn);

the correct instructions are decoded (i.e. it does not skip
any instructions after a 16 bit instruction), indeed the results
are correct apart from the fact that it prints out two extra
instruction bytes for 16 bit instructions.

The attached files are generated like this:-
   dw32as -a test.asm > test.lst
a.out was generated by
   dw32as test.asm

Then with the unmodified dw32-ibld.c file
   dw32objdump -D a.out > test.dmp

and with the modified dw32-ibld.c file
   dw32objdump -D a.out > test.dmp32

I am not sure where the Gremlin is.

Obviously the instruction length is being correctly decoded in 
at least one place (where ever it is which decides how many 
bytes have been consumed by an instruction), but not in 
the extract_insn_normal function dw32-ibld.c.

The instruction bit length is correct in the CGEN_IFMT structs
generated in dw32-opc.c

Any ideas?

Mike Chapman

PS I am using binutils 2.13 release
and a recently checked out cgen from 
:pserver:anoncvs@sources.redhat.com:/cvs/src

I can send a whole load more of the files if you are 
interested.