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

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi,
While analyzing code of CGEN I have found next code:
; Return the definition of an instruction value entry.

(define (gen-ivalue-entry insn)
  (string-list "{ "
               "0x" (number->string (insn-value insn) 16)
               (if #f ; (ifmt-opcodes-beyond-base? (insn-ifmt insn))
                   (string-list ", { "
                                ; ??? wip: opcode values beyond the base
insn
                                "0 }")
                   "")
               " }")
)

and

; Given INSN, return the sum of the constant values in the insn
; (i.e. the opcode field).
;
; See also (compute-insn-base-mask).
;
; FIXME: For non-fixed-length ISAs, using this doesn't feel right.

(define (insn-value insn)
  (if (elm-get insn '/insn-value)
      (elm-get insn '/insn-value)
      (let* ((base-len (insn-base-mask-length insn))
             (value (apply +
                           (map (lambda (fld) (ifld-value fld base-len
(ifld-get-value fld)))
                                (find ifld-constant?
                                      (ifields-base-ifields (insn-iflds
insn))))
                           )))
        (elm-set! insn '/insn-value value)
        value))
)

Can anybody add support for non-fixed-length ISAs?

Best regards,
Sergey Belyashov
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi -

> While analyzing code of CGEN I have found next code:
> [...]
> Can anybody add support for non-fixed-length ISAs?

I am not expecting major cgen improvements.  However, if your
base-insn-size is large enough to contain all the opcode-like
bits of your largest possible instruction, you may not need
those improvements.

- FChE

Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi,
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).

Best regards,
Sergey Belyashov


пн, 27 апр. 2020 г., 19:29 Frank Ch. Eigler <[hidden email]>:

> Hi -
>
> > While analyzing code of CGEN I have found next code:
> > [...]
> > Can anybody add support for non-fixed-length ISAs?
>
> I am not expecting major cgen improvements.  However, if your
> base-insn-size is large enough to contain all the opcode-like
> bits of your largest possible instruction, you may not need
> those improvements.
>
> - FChE
>
>
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
I have tried to increase base-insn-bitsize to 32, but nothing is
changed. z80_cgen_insn_opcode_table in z80-opc.c contains sum of
instruction bytes: 0xED 0x45 -> 0x132

Best regards,
Sergey Belyashov

пн, 27 апр. 2020 г. в 20:00, Sergey Belyashov <[hidden email]>:

> Hi,
> 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).
>
> Best regards,
> Sergey Belyashov
>
>
> пн, 27 апр. 2020 г., 19:29 Frank Ch. Eigler <[hidden email]>:
>
>> Hi -
>>
>> > While analyzing code of CGEN I have found next code:
>> > [...]
>> > Can anybody add support for non-fixed-length ISAs?
>>
>> I am not expecting major cgen improvements.  However, if your
>> base-insn-size is large enough to contain all the opcode-like
>> bits of your largest possible instruction, you may not need
>> those improvements.
>>
>> - FChE
>>
>>
Reply | Threaded
Open this post in threaded view
|

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

Jose E. Marchesi
In reply to this post by Sourceware - cgen list mailing list

    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.)
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
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 <[hidden email]>:

>
>     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.)
>
Reply | Threaded
Open this post in threaded view
|

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

Jose E. Marchesi

    Ok, I understand.
   
    I try to do next experiment:
    set (base-insn-bitsize 24) in ISA definition (without it CGEN fails)


Fails how?
Also, can we see your field definitions? (f-0 and f-1).
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Yes. Full source:
https://github.com/b-s-a/binutils-gdb/blob/z80-cgen/cpu/z80.cpu

пн, 27 апр. 2020 г., 23:01 Jose E. Marchesi <[hidden email]>:

>
>     Ok, I understand.
>
>     I try to do next experiment:
>     set (base-insn-bitsize 24) in ISA definition (without it CGEN fails)
>
>
> Fails how?
> Also, can we see your field definitions? (f-0 and f-1).
>
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
In reply to this post by Jose E. Marchesi
Hi

Without increase of base-insn-bitsize no error is happened. Error was
caused if I use ifields more than 8 bit size.

In any case, currently CGEN cannot handle CISC ISAs like x86 and z80... :'(

Best regards,
Sergey Belyashov

пн, 27 апр. 2020 г. в 23:01, Jose E. Marchesi <[hidden email]>:

>
>     Ok, I understand.
>
>     I try to do next experiment:
>     set (base-insn-bitsize 24) in ISA definition (without it CGEN fails)
>
>
> Fails how?
> Also, can we see your field definitions? (f-0 and f-1).
>
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi,

Can anybody help me, how to correctly implement Zilog Z80 (and
derivatives) instruction decode table switching in CGEN? For example,
the main table has 1 byte instruction and possibly 1-2 bytes of
immediate operand. There are four (ez80 has eight) pseudo instructions
which switches tables for current instruction:
* 0xCB - next byte is rotation or bit manipulation instruction code,
no optional operands;
* 0xED - next byte is instruction of extended instruction set,
possible 1-2 bytes of immediate operand;
* 0xDD/0xFD - switches use of H, L and HL registers to IX/IY on main
and 0xCB tables (here is difficult, because always added immediate
before instruction code: 0xDD 0xCB 0x07 0x3E - "srl (ix+7)").
I think, it should be done in following way:
* it is need to create 5 ISAs: isa_00, isa_cb, isa_ed, isa_ii_00, isa_ii_cb
* opcodes 0xCB, 0xDD, 0xED, 0xFD just switches ISA for current instruction
* <I do not know what I need to do for assembler support, how to parse
by all tables>

Best regards,
Sergey Belyashov
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi -

> Can anybody help me, how to correctly implement Zilog Z80 (and
> derivatives) [...]

OK.  I have no fresh wisdom on this, but:

> * 0xCB - next byte is rotation or bit manipulation instruction code,
> no optional operands;
> * 0xED - next byte is instruction of extended instruction set,
> possible 1-2 bytes of immediate operand;
> * 0xDD/0xFD - switches use of H, L and HL registers to IX/IY on main
> and 0xCB tables (here is difficult, because always added immediate
> before instruction code: 0xDD 0xCB 0x07 0x3E - "srl (ix+7)").

.... these sound like they could fit into a single isa.  You could
have a family of ifields, one set for each of these prefix
combinations.  (Many could have different names and bit offsets but be
otherwise the same.)  Then for each instruction, you would have a set
of separate define-instruction's for each prefix combination (!),
using the corresponding ifields.  Ideally, use a cgen macro to
generate the separate define-instructions, to factor out the
commonalities.


> * <I do not know what I need to do for assembler support, how to parse
> by all tables>

I believe keeping it all in one ISA should make assembler / simulator
support rather easier.


- FChE

Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi,

Thank you for your response.

> .... these sound like they could fit into a single isa.  You could
> have a family of ifields, one set for each of these prefix
> combinations.  (Many could have different names and bit offsets but be
> otherwise the same.)  Then for each instruction, you would have a set
> of separate define-instruction's for each prefix combination (!),
> using the corresponding ifields.  Ideally, use a cgen macro to
> generate the separate define-instructions, to factor out the
> commonalities.

I have already tried to stay within one ISA but my attempt fails. You
may look here for full source of my try:
https://github.com/b-s-a/binutils-gdb/blob/z80-cgen/cpu/z80.cpu
(invalid decoder is generated for last 2 lines - "reti" (ED 4D) and
"retn" (ED 45) instructions, I have tried many types of ifields with
same result, but these are simpler to read). I cannot understand what
I'm doing wrong.

Best regards,
Sergey Belyashov
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi -

> I have already tried to stay within one ISA but my attempt fails. You
> may look here for full source of my try:

OK, yeah sounds like you tried along the same direction!
I don't see anything obviously wrong.

> https://github.com/b-s-a/binutils-gdb/blob/z80-cgen/cpu/z80.cpu
> (invalid decoder is generated for last 2 lines - "reti" (ED 4D) and
> "retn" (ED 45) instructions, I have tried many types of ifields with
> same result, but these are simpler to read). I cannot understand what
> I'm doing wrong.

Does it work if you comment out all other instructions?  If yes, then
I'd approach it with a bisection-like procedure to identify the real
source of conflict.

- FChE

Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi,

> Does it work if you comment out all other instructions?  If yes, then
> I'd approach it with a bisection-like procedure to identify the real
> source of conflict.

I have tried it. Result is the same: ifields are just added (part of
generated z80-opc.c):

/* The instruction table.  */

static const CGEN_OPCODE z80_cgen_insn_opcode_table[MAX_INSNS] =
{
  /* Special null first entry.
     A `num' value of zero is thus invalid.
     Also, the special `invalid' insn resides here.  */
  { { 0, 0, 0, 0 }, {{0}}, 0, {0}},
/* retn */
  {
    { 0, 0, 0, 0 },
    { { MNEM, 0 } },
    & ifmt_retn, { 0x132 } //must be 0xED, 0x45
  },
/* reti */
  {
    { 0, 0, 0, 0 },
    { { MNEM, 0 } },
    & ifmt_retn, { 0x13a } //must be 0xED, 0x4D
  },
};

Also I have tried to make 0xED00 instead of 0xED and 0x4500 instead of
0x45/0x4D, generated C-code looks more correct but does not
disassemble 0xed 0x45 opcode.

Best regards,
Sergey Belyashov
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi -

> I have tried it. Result is the same: ifields are just added (part of
> generated z80-opc.c):

I'm unfortunately unable to actually run cgen here (apparent
incompatibility with "new" fedora32-level guile), so am only guessing
that you could try setting the cpu base-insn-size to 16 or even 32:
enough bits to tell the instructions apart.

- FChE

Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list

>> I have tried it. Result is the same: ifields are just added (part of
>> generated z80-opc.c):
>
> I'm unfortunately unable to actually run cgen here (apparent
> incompatibility with "new" fedora32-level guile), so am only guessing
> that you could try setting the cpu base-insn-size to 16 or even 32:
> enough bits to tell the instructions apart.

That looks like the right approach.

Currently CGEN does not support having opcodes (constant fields) past
the base part of the insn, which by the way is limited to a maximum of
32-bit.
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
But Zilog eZ80 CPU has instructions up to 6 bytes long: like ld.il bc,(Mmn)
(lil/sil prefix 0xed prefix <opcode> <n> <m> <M>) .

ср, 12 авг. 2020 г., 21:53 Jose E. Marchesi <[hidden email]>:

>
> >> I have tried it. Result is the same: ifields are just added (part of
> >> generated z80-opc.c):
> >
> > I'm unfortunately unable to actually run cgen here (apparent
> > incompatibility with "new" fedora32-level guile), so am only guessing
> > that you could try setting the cpu base-insn-size to 16 or even 32:
> > enough bits to tell the instructions apart.
>
> That looks like the right approach.
>
> Currently CGEN does not support having opcodes (constant fields) past
> the base part of the insn, which by the way is limited to a maximum of
> 32-bit.
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
Hi -

> But Zilog eZ80 CPU has instructions up to 6 bytes long: like ld.il bc,(Mmn)
> (lil/sil prefix 0xed prefix <opcode> <n> <m> <M>) .

You don't have to include pure operands in those 6.  Just the
opcode-containing bytes that tell cgen-level instructions apart.

- FChE

Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list

>> But Zilog eZ80 CPU has instructions up to 6 bytes long: like ld.il bc,(Mmn)
>> (lil/sil prefix 0xed prefix <opcode> <n> <m> <M>) .
>
> You don't have to include pure operands in those 6.  Just the
> opcode-containing bytes that tell cgen-level instructions apart.

Yeah, just make sure that every (f-FOO CST) expression in instruction
formats (+ ... ) are contained in the base-insn.

Instruction operands can appear beyond the base insn without problems.
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - cgen list mailing list
>
> >> But Zilog eZ80 CPU has instructions up to 6 bytes long: like ld.il
> bc,(Mmn)
> >> (lil/sil prefix 0xed prefix <opcode> <n> <m> <M>) .
> >
> > You don't have to include pure operands in those 6.  Just the
> > opcode-containing bytes that tell cgen-level instructions apart.
>
> Yeah, just make sure that every (f-FOO CST) expression in instruction
> formats (+ ... ) are contained in the base-insn.
>
> Instruction operands can appear beyond the base insn without problems.



Ok. How to handle variable size instructions then? For example:
NOP - 0x00
NEG - 0xed 0x44
RLC B - 0xcb 0x00
LD HL, 0x1234 - 0x21 0x34 0x12
LD IY, 0x1234 - 0xfd 0x21 0x34 0x12
LD DE, (0x1234) - 0xed 0x5b 0x34 0x12
RR (IX+9) - 0xdd 0xcb 0x09 0x1e (here 0x09 is 8-bit signed immediate)
12