From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 391 invoked by alias); 22 Feb 2020 15:11:44 -0000 Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org Received: (qmail 375 invoked by uid 89); 22 Feb 2020 15:11:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 22 Feb 2020 15:11:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582384295; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/sl8IMEc6bfv1ppEa/iKq6/Ys0U8GxYE6nJHQljucb4=; b=U/YIB8H7fH2MUSHAzo/Arr2Ori5Lfb3p0UzMp+j1Xpqpir9Rdodw31wnAoXwQwnuKan05J 1/qX0qkOiZvuYbaoeKR5ZrkGkSGB/p0sk4nDRMvT90CY9u02vffG7hNQBZRfYr1PUW0szr cFkLd2+T9s40mHJrUzndiuhFEla77n4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-103-GcSiulrpMhO16cnFZIWMNQ-1; Sat, 22 Feb 2020 10:11:33 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A84C2100550E; Sat, 22 Feb 2020 15:11:32 +0000 (UTC) Received: from redhat.com (ovpn-116-36.phx2.redhat.com [10.3.116.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 887AA90F7C; Sat, 22 Feb 2020 15:11:32 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.92.3) (envelope-from ) id 1j5WRH-0003j2-5G; Sat, 22 Feb 2020 10:11:31 -0500 Date: Sat, 22 Feb 2020 15:11:00 -0000 From: "Frank Ch. Eigler" To: Sergey Belyashov Cc: cgen@sourceware.org Subject: Re: Writing .cpu file for Z80 Message-ID: <20200222151131.GD9795@redhat.com> References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2020-q1/txt/msg00012.txt Hi - > The Z80 CPU uses prefix opcodes to change opcode tables and operation > registers. For example, <0x21 0x34 0x12> is "LD HL,0x1234", but <0xdd 0x21 > 0x34 0x12> is "LD IX,0x1234". Do I need write both instructions or is it > possible to write rule which selects proper instruction set or extract > correct register index? Consider writing prefix opcodes as a normal part of the instruction (so include them in the base-insn-bitsize). So you'd need two separate instructions, one with and one without. You may be able to use cgen macros to generate both flavours from one piece of declaration. > Z80 has special rule to form indirect memory operations using index > registers. There immediate offset is always third byte of instruction. For > example: <0xdd 0x34 0x12> is "INC (IX+0x12)", <0xfd 0x36 0xfe 0xab> is "LD > (IY-0x02),0xAB"... But there are "strange" instructions, where index is > placed before opcode itself: <0xdd 0xcb 0x10 0x1e> is "RR (IX+0x10)" (<0x= cb > 0x1e> is "RR (HL)", <0xcb> is opcode prefix, which select another opcode > table) and undocumented one <0xdd 0xcb 0x10 0x1f> "RR (IX+0x10),A". Should > I write 2 instructions types? Probably, if the same operands are not in the same place. > eZ80 uses four opcode prefixes (.SIS, .SIL, .LIS, .LIL) which set operati= on > mode (.IL - long instruction (24 bit immediate), .IS - short instruction > (16 bit immediate), .S - 16 bit processing, .L - 24 bit processing): <0x40 > 0x21 0x34 0x12> is "LD.SIS HL,0x1234" and <0x5b 0x21 0x56 0x34 0x12> is > "LD.LIL HL,0x123456". These prefixes can be applied to all instructions > (but it has no sense for part of instructions). Moreover, assembler should > support short mode of instructions (.S, .L, .IS, .IL), which is completed > by assembler depending on compiling mode (ADL or Z80). Should I generate > all possible combinations (9 x instruction_set)? Is there more correct > solution? You may be able to represent tehse opcode prefix bytes as an operand, and have a special asm parser/printer that sets them from the .SIS etc mnemonic suffix. Or you can go brute-force and generate the family of 9 (!) instructions with a cgen macro. (There may be other ways too.) - FChE