problems with 48 bit instruction architecture...

[Alan Lehotsky <qsmgmt at earthlink dot net>]

I'm looking at a machine with 48 bit instructions (fixed length).  I'm hosting on Ubuntu x86 linux.

The target architecture is  little-endian, and I've described the machine with

     (define-arch
           ....
          (default-alignment aligned)
          (insn-lsb0? #t)
          (machs  xyz)
          (isas xyz))

    (define-isa (name xyz)
           (default-insn-word-bitsize 48)
           (default-insn-bitsize 48)
           (base-insn-bitsize 48))


and then defined the fields of the instruction beginning at bit 47, the MSB of what should be byte 0 of a 6 byte instruction.



BUT, when I run cgen, I find that my xyz-opc.c file gets compilation errors because the CGEN_IFMT entries are being given
hex literals like 

        oxfc0000000000

which won't fit into the CGEN_INSN_INT type field (because that's defined as 'int' in cgen.h.  If I change cgen.h to have CGEN_INSN_INT defined as uint64, then my opcodes stuff all compiles and the assembler builds.  But the generated .o
file has the instruction bytes output (according to objdump) for a "ret 4" instruction comes out as
    
   0000    0400c200 0000    

where the first '0000' is the address in the text section.  'od -t x1' confirms that the 0x04 is the  first byte

which is exactly backwards AND missing the opcode.  Based on my instruction definitions, I would expect to see

       1c00002c 0004

where 0x1c is the primary opcode.  I could live with the bytes being out-of-order - it would be easy to flip them since instructions and data are separate address spaces on this machine - but the missing opcode is a non-starter.

So, I imagine I'm doing something stupid, but I don't see what it is...

I've checked that CGEN_INT_INSN_P is defined as 0 in xyz-desc.h, so I should be using the byte-string representation.