public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* BUG: non-fixed-length ISAs are unsupported for now
@ 2020-04-23 13:37 Sergey Belyashov
  2020-04-27 16:29 ` Frank Ch. Eigler
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-04-23 13:37 UTC (permalink / raw)
  To: cgen

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-23 13:37 BUG: non-fixed-length ISAs are unsupported for now Sergey Belyashov
@ 2020-04-27 16:29 ` Frank Ch. Eigler
  2020-04-27 17:00   ` Sergey Belyashov
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Ch. Eigler @ 2020-04-27 16:29 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: cgen

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-27 16:29 ` Frank Ch. Eigler
@ 2020-04-27 17:00   ` Sergey Belyashov
  2020-04-27 17:52     ` Sergey Belyashov
  2020-04-27 18:03     ` Jose E. Marchesi
  0 siblings, 2 replies; 24+ messages in thread
From: Sergey Belyashov @ 2020-04-27 17:00 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: cgen

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 <fche@redhat.com>:

> 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
>
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-27 17:00   ` Sergey Belyashov
@ 2020-04-27 17:52     ` Sergey Belyashov
  2020-04-27 18:03     ` Jose E. Marchesi
  1 sibling, 0 replies; 24+ messages in thread
From: Sergey Belyashov @ 2020-04-27 17:52 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: cgen

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 <sergey.belyashov@gmail.com>:

> 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 <fche@redhat.com>:
>
>> 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
>>
>>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-27 17:00   ` Sergey Belyashov
  2020-04-27 17:52     ` Sergey Belyashov
@ 2020-04-27 18:03     ` Jose E. Marchesi
  2020-04-27 19:34       ` Sergey Belyashov
  1 sibling, 1 reply; 24+ messages in thread
From: Jose E. Marchesi @ 2020-04-27 18:03 UTC (permalink / raw)
  To: Sergey Belyashov via Cgen; +Cc: Frank Ch. Eigler, Sergey Belyashov


    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.)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-27 18:03     ` Jose E. Marchesi
@ 2020-04-27 19:34       ` Sergey Belyashov
  2020-04-27 20:01         ` Jose E. Marchesi
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-04-27 19:34 UTC (permalink / raw)
  To: Jose E. Marchesi; +Cc: Sergey Belyashov via Cgen, Frank Ch. Eigler

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 <jemarch@gnu.org>:

>
>     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.)
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-27 19:34       ` Sergey Belyashov
@ 2020-04-27 20:01         ` Jose E. Marchesi
  2020-04-27 20:23           ` Sergey Belyashov
  2020-04-29 19:11           ` Sergey Belyashov
  0 siblings, 2 replies; 24+ messages in thread
From: Jose E. Marchesi @ 2020-04-27 20:01 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: Sergey Belyashov via Cgen, Frank Ch. Eigler


    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).

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-27 20:01         ` Jose E. Marchesi
@ 2020-04-27 20:23           ` Sergey Belyashov
  2020-04-29 19:11           ` Sergey Belyashov
  1 sibling, 0 replies; 24+ messages in thread
From: Sergey Belyashov @ 2020-04-27 20:23 UTC (permalink / raw)
  To: Jose E. Marchesi; +Cc: Sergey Belyashov via Cgen, Frank Ch. Eigler

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

пн, 27 апр. 2020 г., 23:01 Jose E. Marchesi <jemarch@gnu.org>:

>
>     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).
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-27 20:01         ` Jose E. Marchesi
  2020-04-27 20:23           ` Sergey Belyashov
@ 2020-04-29 19:11           ` Sergey Belyashov
  2020-07-30  9:11             ` Sergey Belyashov
  1 sibling, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-04-29 19:11 UTC (permalink / raw)
  To: Jose E. Marchesi; +Cc: Sergey Belyashov via Cgen, Frank Ch. Eigler

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 <jemarch@gnu.org>:

>
>     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).
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-04-29 19:11           ` Sergey Belyashov
@ 2020-07-30  9:11             ` Sergey Belyashov
  2020-08-11 15:38               ` Frank Ch. Eigler
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-07-30  9:11 UTC (permalink / raw)
  To: Sergey Belyashov via Cgen

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-07-30  9:11             ` Sergey Belyashov
@ 2020-08-11 15:38               ` Frank Ch. Eigler
  2020-08-11 15:57                 ` Sergey Belyashov
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Ch. Eigler @ 2020-08-11 15:38 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: Sergey Belyashov via Cgen

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-11 15:38               ` Frank Ch. Eigler
@ 2020-08-11 15:57                 ` Sergey Belyashov
  2020-08-11 16:08                   ` Frank Ch. Eigler
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-08-11 15:57 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Sergey Belyashov via Cgen

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-11 15:57                 ` Sergey Belyashov
@ 2020-08-11 16:08                   ` Frank Ch. Eigler
  2020-08-12 13:59                     ` Sergey Belyashov
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Ch. Eigler @ 2020-08-11 16:08 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: Sergey Belyashov via Cgen

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-11 16:08                   ` Frank Ch. Eigler
@ 2020-08-12 13:59                     ` Sergey Belyashov
  2020-08-12 18:36                       ` Frank Ch. Eigler
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-08-12 13:59 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Sergey Belyashov via Cgen

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 13:59                     ` Sergey Belyashov
@ 2020-08-12 18:36                       ` Frank Ch. Eigler
  2020-08-12 18:53                         ` Jose E. Marchesi
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Ch. Eigler @ 2020-08-12 18:36 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: Sergey Belyashov via Cgen

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 18:36                       ` Frank Ch. Eigler
@ 2020-08-12 18:53                         ` Jose E. Marchesi
  2020-08-12 19:19                           ` Sergey Belyashov
  0 siblings, 1 reply; 24+ messages in thread
From: Jose E. Marchesi @ 2020-08-12 18:53 UTC (permalink / raw)
  To: Frank Ch. Eigler via Cgen; +Cc: Sergey Belyashov, Frank Ch. Eigler


>> 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 18:53                         ` Jose E. Marchesi
@ 2020-08-12 19:19                           ` Sergey Belyashov
  2020-08-12 19:21                             ` Frank Ch. Eigler
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-08-12 19:19 UTC (permalink / raw)
  To: Jose E. Marchesi; +Cc: Frank Ch. Eigler via Cgen, Frank Ch. Eigler

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 <jose.marchesi@oracle.com>:

>
> >> 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 19:19                           ` Sergey Belyashov
@ 2020-08-12 19:21                             ` Frank Ch. Eigler
  2020-08-12 19:27                               ` Jose E. Marchesi
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Ch. Eigler @ 2020-08-12 19:21 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: Jose E. Marchesi, Frank Ch. Eigler via Cgen

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 19:21                             ` Frank Ch. Eigler
@ 2020-08-12 19:27                               ` Jose E. Marchesi
  2020-08-12 19:44                                 ` Sergey Belyashov
  0 siblings, 1 reply; 24+ messages in thread
From: Jose E. Marchesi @ 2020-08-12 19:27 UTC (permalink / raw)
  To: Frank Ch. Eigler via Cgen; +Cc: Sergey Belyashov, Frank Ch. Eigler


>> 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 19:27                               ` Jose E. Marchesi
@ 2020-08-12 19:44                                 ` Sergey Belyashov
  2020-08-12 19:57                                   ` Frank Ch. Eigler
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-08-12 19:44 UTC (permalink / raw)
  To: Jose E. Marchesi; +Cc: Frank Ch. Eigler via Cgen, Frank Ch. Eigler

>
> >> 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)

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 19:44                                 ` Sergey Belyashov
@ 2020-08-12 19:57                                   ` Frank Ch. Eigler
  2020-08-13 13:34                                     ` Sergey Belyashov
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Ch. Eigler @ 2020-08-12 19:57 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: Jose E. Marchesi, Frank Ch. Eigler via Cgen

Hi -

> 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)

Simply, make no change other than setting the base-insn large enough
to contain all the opcode fields.  Amongst all these cases, that seems
to be 16 or perhaps 24 bits.  I suggest trying 32.

- FChE


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-12 19:57                                   ` Frank Ch. Eigler
@ 2020-08-13 13:34                                     ` Sergey Belyashov
  2020-08-13 14:32                                       ` Frank Ch. Eigler
  0 siblings, 1 reply; 24+ messages in thread
From: Sergey Belyashov @ 2020-08-13 13:34 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Jose E. Marchesi, Frank Ch. Eigler via Cgen

Hi,

> Simply, make no change other than setting the base-insn large enough
> to contain all the opcode fields.  Amongst all these cases, that seems
> to be 16 or perhaps 24 bits.  I suggest trying 32.

When I increase base-insn-bitsize to 32 of ISA definition objdump
fails with: stack smashing error. Valgrind shows next backtrace:
00000000 <.text>:
*** stack smashing detected ***: terminated
==325050==
==325050== Process terminating with default action of signal 6 (SIGABRT)
==325050==    at 0x48B718B: raise (raise.c:51)
==325050==    by 0x4896858: abort (abort.c:79)
==325050==    by 0x49013ED: __libc_message (libc_fatal.c:155)
==325050==    by 0x49A39B9: __fortify_fail (fortify_fail.c:26)
==325050==    by 0x49A3985: __stack_chk_fail (stack_chk_fail.c:24)
==325050==    by 0x17BE43: default_print_insn (z80-dis.c:448)
==325050==    by 0x17C0AA: print_insn_z80 (z80-dis.c:567)
==325050==    by 0x131CB3: disassemble_bytes (objdump.c:2768)
==325050==    by 0x13360E: disassemble_section (objdump.c:3340)
==325050==    by 0x1A9E99: bfd_map_over_sections (section.c:1377)
==325050==    by 0x133C2E: disassemble_data (objdump.c:3484)
==325050==    by 0x137079: dump_bfd (objdump.c:4866)

But in C file RETI/RETN instructions are implemented as:
/* retn */
  {
    { 0, 0, 0, 0 },
    { { MNEM, 0 } },
    & ifmt_retn, { 0x132 } //why?!?
  },
/* reti */
  {
    { 0, 0, 0, 0 },
    { { MNEM, 0 } },
    & ifmt_retn, { 0x13a } //why?!?
  },

Definition of these instructions:

(dnf f-0 "whole byte 0" ((MACH z80) all-isas) 7 8)
(dnf f-1  "whole byte 1" ((MACH z80) all-isas) 15 8)

(dni retn       "return from NMI handler" (all-isas UNCOND-CTI) "retn"
(+ (f-0 #xED) (f-1 #x45)) () ())
(dni reti       "return from INT handler" (all-isas UNCOND-CTI) "reti"
(+ (f-0 #xED) (f-1 #x4D)) () ())

default-insn-bitsize in ISA definition is kept 8. If I set it 32 too,
then implementation of instructions looks correct, but stack smashing
exists too.

Best regards,
Sergey Belyashov

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-13 13:34                                     ` Sergey Belyashov
@ 2020-08-13 14:32                                       ` Frank Ch. Eigler
  2020-08-13 14:47                                         ` Sergey Belyashov
  0 siblings, 1 reply; 24+ messages in thread
From: Frank Ch. Eigler @ 2020-08-13 14:32 UTC (permalink / raw)
  To: Sergey Belyashov; +Cc: Jose E. Marchesi, Frank Ch. Eigler via Cgen

Hi -

> When I increase base-insn-bitsize to 32 of ISA definition objdump
> fails with: stack smashing error. Valgrind shows next backtrace:
> [...]
> ==325050==    by 0x17BE43: default_print_insn (z80-dis.c:448)
> ==325050==    by 0x17C0AA: print_insn_z80 (z80-dis.c:567)
> ==325050==    by 0x131CB3: disassemble_bytes (objdump.c:2768)
> ==325050==    by 0x13360E: disassemble_section (objdump.c:3340)

OK, so things went much further.  I'd work backward from this new
error rather than change the base-insn-size back.  Can you push to
your branch all the cgen-generated opcodes/etc. code?

- FChE


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: BUG: non-fixed-length ISAs are unsupported for now
  2020-08-13 14:32                                       ` Frank Ch. Eigler
@ 2020-08-13 14:47                                         ` Sergey Belyashov
  0 siblings, 0 replies; 24+ messages in thread
From: Sergey Belyashov @ 2020-08-13 14:47 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Jose E. Marchesi, Frank Ch. Eigler via Cgen

> OK, so things went much further.  I'd work backward from this new
> error rather than change the base-insn-size back.  Can you push to
> your branch all the cgen-generated opcodes/etc. code?

Done

Best regards,
Sergey Belyashov

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2020-08-13 14:47 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-23 13:37 BUG: non-fixed-length ISAs are unsupported for now Sergey Belyashov
2020-04-27 16:29 ` Frank Ch. Eigler
2020-04-27 17:00   ` Sergey Belyashov
2020-04-27 17:52     ` Sergey Belyashov
2020-04-27 18:03     ` Jose E. Marchesi
2020-04-27 19:34       ` Sergey Belyashov
2020-04-27 20:01         ` Jose E. Marchesi
2020-04-27 20:23           ` Sergey Belyashov
2020-04-29 19:11           ` Sergey Belyashov
2020-07-30  9:11             ` Sergey Belyashov
2020-08-11 15:38               ` Frank Ch. Eigler
2020-08-11 15:57                 ` Sergey Belyashov
2020-08-11 16:08                   ` Frank Ch. Eigler
2020-08-12 13:59                     ` Sergey Belyashov
2020-08-12 18:36                       ` Frank Ch. Eigler
2020-08-12 18:53                         ` Jose E. Marchesi
2020-08-12 19:19                           ` Sergey Belyashov
2020-08-12 19:21                             ` Frank Ch. Eigler
2020-08-12 19:27                               ` Jose E. Marchesi
2020-08-12 19:44                                 ` Sergey Belyashov
2020-08-12 19:57                                   ` Frank Ch. Eigler
2020-08-13 13:34                                     ` Sergey Belyashov
2020-08-13 14:32                                       ` Frank Ch. Eigler
2020-08-13 14:47                                         ` Sergey Belyashov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).