From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114810 invoked by alias); 22 Feb 2020 19:19:12 -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 114798 invoked by uid 89); 22 Feb 2020 19:19:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-2.3 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,FREEMAIL_FROM,GARBLED_BODY,GIT_PATCH_1,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy==d0=b5=d0=b2=d1, HX-Google-DKIM-Signature:AIA, H*c:alternative?= X-HELO: mail-qk1-f179.google.com Received: from mail-qk1-f179.google.com (HELO mail-qk1-f179.google.com) (209.85.222.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 22 Feb 2020 19:19:09 +0000 Received: by mail-qk1-f179.google.com with SMTP id l13so2471244qkk.2 for ; Sat, 22 Feb 2020 11:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DNQNisbKNb1ldhqjbjhkip6vd/LrRLdwWRoq27SkcEs=; b=BP0xatfP/qQhXXBPavH2J5qs+7uC2tt8SJ821ef2v/AOuAz6JJIcq90pX/17YYglBG s2MhWdn87Y0k+RZTvoDwSS2fK69gm2XI9eWT9PUvGkBnH4i5hmcVKjqyDymwITmx98Aw 6tky802BFg1Vv6XTxC2qyyfv4WcplfjXt7tiSQ9BewAQAtlke2OJodV14SgqDLkOiwhp 7EpYlkO0cXfqm9TDab1BIU8WV7u4ueoc8I65wnVbrBGRrvU9MdzK+EiupkZZDB6tZeTN xIHPWygtDb1HOr47b2bE73znj8VqrRVo3iqAmhVoo0CBtx/nsx3JgD58UBRpvBpW3eMr axkg== MIME-Version: 1.0 References: <20200222151131.GD9795@redhat.com> In-Reply-To: <20200222151131.GD9795@redhat.com> From: Sergey Belyashov Date: Sat, 22 Feb 2020 19:19:00 -0000 Message-ID: Subject: Re: Writing .cpu file for Z80 To: "Frank Ch. Eigler" Cc: cgen@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-q1/txt/msg00013.txt Hi Thank you. 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 just brutforced... 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? Best regards, Sergey Belyashov =D1=81=D0=B1, 22 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., 18:11 Frank Ch. Ei= gler : > 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)" > (<0xcb > > 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 > operation > > 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 complet= ed > > 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 > >