From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114585 invoked by alias); 23 Feb 2020 00:03:25 -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 114568 invoked by uid 89); 23 Feb 2020 00:03:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=mechanisms, About, H*i:CAOe0RDxr, H*MI:sk:DiZbYT- 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; Sun, 23 Feb 2020 00:03:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582416202; 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=Oug2Pa9P6SfgrAPU1VdPrcSOyAJc/ujOTftTiNEDVsU=; b=Ad5040rY0DW4fzOi3hklMjY3/paMgtBqbXUsayaf4WGxxRY+ATN4+QocpPh+dph+1BGs/g wqjrVSChNF8dHMbnjnNCxOJB8k/OipJ4GsEyMRcdkl0EveyyoD7Ye6j9U0759mAGpmXDp1 MGsIiyddswMLub8skYscNBTT9gjCHnM= 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-79-t6iezkttP922n-ay21Uh7A-1; Sat, 22 Feb 2020 19:03:20 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 454D9800D5E; Sun, 23 Feb 2020 00:03:19 +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 283C15D9CA; Sun, 23 Feb 2020 00:03:19 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.92.3) (envelope-from ) id 1j5ejt-0004EE-Ov; Sat, 22 Feb 2020 19:03:17 -0500 Date: Sun, 23 Feb 2020 00:03:00 -0000 From: "Frank Ch. Eigler" To: Sergey Belyashov Cc: cgen@sourceware.org Subject: Re: Writing .cpu file for Z80 Message-ID: <20200223000317.GE9795@redhat.com> References: <20200222151131.GD9795@redhat.com> 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/msg00014.txt Hi - > About sufficies. Short sufficies (.s, .l, .is, .il) should be converted to > the full one by assembler using ADL (acronim for address & data long) mode > state, which is set by programmer (command line options or directive > .assume ADL=3D1 or .assume ADL=3D0), so these short sufficies cannot be j= ust > brutforced... Aha. If it were just an operand field, a parser could be stateful and fill that in. If it's a whole different opcode prefix/pattern, then a larger custom parser. Try things :-) > Another question. Z80 instruction set uses same mnemonic for completely > different (comparing to other cpus) instructions: > LD A,n ; 8-bit load immediate > LD HL,nn ; 16-bit load immediate > LD A,(nn) ; 8-bit direct memory load > LD (IX+5),A ;8-bit indirect indexed memory store > LD (nn),HL ;16-bit direct memory store... > Can it cause ASM parser issues? I believe there is precedent for different addressing modes with the same mnemonic to result in different opcodes. Sorry I'm not fresh enough with the code base to point them out, but there are a couple of mechanisms. cgen's assembler / disassembler interfaces are hookable enough that you can generally make things work even if the abstract cgen model is not quite enough. - FChE