From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27161 invoked by alias); 19 Oct 2009 17:27:59 -0000 Received: (qmail 27141 invoked by uid 22791); 19 Oct 2009 17:27:55 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX X-Spam-Check-By: sourceware.org Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 17:27:49 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id DD7CC6E3D5; Mon, 19 Oct 2009 10:27:24 -0700 (PDT) Message-ID: <4ADCA17C.8080108@sebabeach.org> Date: Mon, 19 Oct 2009 17:27:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Dmitry Eremin-Solenikov CC: cgen@sources.redhat.com Subject: Re: Instruction w/ prefix References: <4AD7ABC4.3080105@sebabeach.org> <4ADC6A35.4020709@gmail.com> In-Reply-To: <4ADC6A35.4020709@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2009-q4/txt/msg00018.txt.bz2 Dmitry Eremin-Solenikov wrote: > Hello, > > Doug Evans wrote: >> Dmitry Eremin-Solenikov wrote: >>> Hello, >>> >>> I'm using cgen to create binutils port for the CISC architecture >>> (M68HC(S)08 if somebody cares). I've stumbled upon one problem: the is >>> an instruction prefix which can change meaning >>> of the next instruction (basically it then uses SP register instead >>> of IX one). >>> >>> What is the most clean way to do this w/ cgen? I can of course >>> duplicate instruction fields, counting another byte in the beginning, >>> instructions, etc.. This will permit me to catch illegal combinations. >>> OTOH it doesn' look like completely clean idea. >>> >>> What would you suggest? >>> >>> >> >> Hi. Sorry for the slow reply. >> >> I think the right solution (which I wouldn't wait for) is to extend >> cgen to handle instruction prefixes. > > Do you have any ideas how to implement (or at least design) this? > > As for me, the prefix just changes the addressing (prefixed instruction > just uses SP as a base instead of IX register). My current thinking is that they wouldn't be that different from individual instructions, except that they'd have a flag (attribute?) that says "I'm a prefix", and instructions that take prefixes would specify which prefixes are valid, and semantics would have some way of querying/specifying what prefixes are present/required. [There's more details like whether multiple prefixes are valid, if there's a required order of prefixes (I guess), but that's the high order bit, I think.] > >> In the meantime, I would treat the prefix as its own instruction. > > Yep, I've tried this approach. However I've stumbled upon the fact that > cgen just sums all specified values, thus leading me into problems. > > I'm currently looking into how to overcome this. Maybe you can suggest > a sample which I can look upon? > Can you elaborate on "just sums all specified values"? If all the prefixes are their own instructions, what values are summed up? P.S. If one needed a simulator here, I'd create a register, named say h-use-sp-for-base or some such, that specified whether the "use-sp-base prefix" was present, reset it at appropriate times, have the use-sp-base prefix set it, and query the register in appropriate locations. Then you could either choose between SP and IX in every instruction that needs it by querying h-use-sp-base, or you could create a virtual register that returns one of SP or IX depending on the value of h-use-sp. I haven't tried it, but I think that would work. [If it doesn't, I think it *should* work so let's fix it if it doesn't.]