Re: BUG: non-fixed-length ISAs are unsupported for now

Ok, I understand.

I try to do next experiment:
set (base-insn-bitsize 24) in ISA definition (without it CGEN fails)
(dni retn       "return from NMI handler" (all-isas UNCOND-CTI) "retn" (+
(f-0 #xED) (f-1 #x4500)) () ())
(dni reti       "return from INT handler" (all-isas UNCOND-CTI) "reti" (+
(f-0 #xED) (f-1 #x4D00)) () ())

and now:

static const CGEN_IFMT ifmt_retn ATTRIBUTE_UNUSED = {
  16, 16, 0xff, { { F (F_0) }, { F (F_1) }, { 0 } }
};

/* retn */
  {
    { 0, 0, 0, 0 },
    { { MNEM, 0 } },
    & ifmt_retn, { 0x45ed }
  },
/* reti */
  {
    { 0, 0, 0, 0 },
    { { MNEM, 0 } },
    & ifmt_retn, { 0x4ded }
  },

code looks more correct, but it does not work properly.


пн, 27 апр. 2020 г. в 21:03, Jose E. Marchesi <[email protected]>:

>
>     Z80 has istructions from 1 byte (nop for example) up to 4 bytes long
> (eZ80
>     up to 6 bytes) including operands 0..2 bytes (eZ80 0..3 bytes). So
>     base-insn-bitsize is set to 8. And it is not enought for 1-3 bytes
> (eZ80
>     1-4) insn code size (w/o immediate operands).
>
> Then your base-insn-bitsize should be 8.
>
> The key here is: how are opcodes expressed in your ISA?  Do they appear
> in the first base insn only, or they are scattered in the optional bytes
> in long instructions?
>
> CGEN currently has two limitations in its implementation:
> 1) It does not support having opcodes (i.e. entries of the form (f-FOO
>    VAL) in (+ ) field descriptions) past the first 64 bits of an
>    instruction.
> 2) It does not support to have opcode fields placed in their own word.
>
> These limitations have bitten me in the BPF port and, at the moment, I
> have a couple of workarounds in place, but it would be nice to remove
> them.
>
> For an example of an instruction set with variable length instructions
> see cpu/ia32.cpu in the CGEN distribution for an example of
> variable-length instruction set.  However, the "FIXME" annotations in
> instructions that (f-reg/opcode 0) are most probably there because that
> opcode field is not applied properly, since it is defined to be in the
> second word of the instruction (limitation (2) above.)
>