From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) by sourceware.org (Postfix) with ESMTPS id 9AE5F385BF81 for ; Mon, 27 Apr 2020 19:34:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9AE5F385BF81 Received: by mail-qk1-x72d.google.com with SMTP id b188so17741582qkd.9 for ; Mon, 27 Apr 2020 12:34:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A+LB+xVGzK0HeB9W/OdJZXsXN+dPHx7SHUYwk6FVCk0=; b=PFre7p8h5lFtRyIdD3eK2iVX6uNDmjcnx5QzzOWnrPQbnqa79LBpEZphfYWiGKpcVX Uxy7xWBbaadEgD3kddiU4sAhJo34lYGr0LOtYhkLtWsNmCtjJ1uclvrLyM4XHCCyV3qI iXWsm7YVQbHZAwzJQVlKFBlhpm2ZOIRpyokVJUZxSDfuYldACDGj17NAcrcjgrnK2RSD R3FSzOwehvERUS6iZAQ1CIGZNNw70jx5n1p9pKF+EbxCRC5XUepiI1JaZ1iKi9dNzXK0 enT5oY1QDgTTVuk0LMZjZfix/YRLKROcN52HNNWAWdxnJum1XTOxqX79FtX1kDtRmQ9G F9/g== X-Gm-Message-State: AGi0PuaEl3oNShbzmYUhcta+LoTmMIzAGi7RUmpqbzuvfLycnjm/k50W 8+zgi9Y0iXmD8S0XpWTrXiO3a5/WVsWVsWMEOzqMvGcjaUDX2g== X-Google-Smtp-Source: APiQypJ/dv/vVFMBkffjWm99RGfzJsNYKF7WdaqTWO32ydkZM1WJ5AR2LhQKhNQEToenEqTNnG/WjPhHww5uCRZOYwc= X-Received: by 2002:a05:620a:1362:: with SMTP id d2mr22774118qkl.256.1588016085124; Mon, 27 Apr 2020 12:34:45 -0700 (PDT) MIME-Version: 1.0 References: <20200427162914.GA21677@redhat.com> <87pnbsztze.fsf@gnu.org> In-Reply-To: <87pnbsztze.fsf@gnu.org> From: Sergey Belyashov Date: Mon, 27 Apr 2020 22:34:34 +0300 Message-ID: Subject: Re: BUG: non-fixed-length ISAs are unsupported for now To: "Jose E. Marchesi" Cc: Sergey Belyashov via Cgen , "Frank Ch. Eigler" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: cgen@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cgen mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 19:34:47 -0000 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 =3D { 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. =D0=BF=D0=BD, 27 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 21:03, Jose E. Mar= chesi : > > 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.) >