From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 368C23858D34 for ; Mon, 27 Apr 2020 18:03:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 368C23858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jemarch@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:41247) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT86Y-0000Nh-8r; Mon, 27 Apr 2020 14:03:42 -0400 Received: from [141.143.193.72] (port=36932 helo=termi.gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jT86X-0001dt-6W; Mon, 27 Apr 2020 14:03:41 -0400 From: "Jose E. Marchesi" To: Sergey Belyashov via Cgen Cc: "Frank Ch. Eigler" , Sergey Belyashov Subject: Re: BUG: non-fixed-length ISAs are unsupported for now References: <20200427162914.GA21677@redhat.com> Date: Mon, 27 Apr 2020 20:03:33 +0200 In-Reply-To: (Sergey Belyashov via Cgen's message of "Mon, 27 Apr 2020 20:00:07 +0300") Message-ID: <87pnbsztze.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, 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 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 18:03:44 -0000 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.)