From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7135 invoked by alias); 13 Dec 2002 14:42:21 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 7127 invoked from network); 13 Dec 2002 14:42:20 -0000 Received: from unknown (HELO miranda.axis.se) (193.13.178.2) by sources.redhat.com with SMTP; 13 Dec 2002 14:42:20 -0000 Received: from ignucius.axis.se (ignucius.axis.se [10.13.1.18]) by miranda.axis.se (8.12.3/8.12.3/Debian -4) with ESMTP id gBDEgHx4021640; Fri, 13 Dec 2002 15:42:17 +0100 Received: from ignucius.axis.se (localhost [127.0.0.1]) by ignucius.axis.se (8.12.3/8.12.3/Debian -4) with ESMTP id gBDEgHG9030572 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 13 Dec 2002 15:42:17 +0100 Received: (from hp@localhost) by ignucius.axis.se (8.12.3/8.12.3/Debian -4) id gBDEgHeR030568; Fri, 13 Dec 2002 15:42:17 +0100 Date: Fri, 13 Dec 2002 06:42:00 -0000 Message-Id: <200212131442.gBDEgHeR030568@ignucius.axis.se> From: Hans-Peter Nilsson To: dje@transmeta.com CC: hans-peter.nilsson@axis.com, cgen@sources.redhat.com In-reply-to: <15865.58703.575946.279017@xris-athlon.transmeta.com> (message from Doug Evans on Fri, 13 Dec 2002 05:49:03 -0800 (PST)) Subject: Re: [RFA:] In -build-operand!, -build-reg-operand, collect the natural mode, not the used mode, X-SW-Source: 2002-q4/txt/msg00084.txt.bz2 > From: Doug Evans > Date: Fri, 13 Dec 2002 05:49:03 -0800 (PST) > Sorry for the delay. Now that I'm back up to speed on the m32r response > times may actually improve (but don't hold your breath of course, sigh). I've still not replied to your reply about the previous patch so no need to be sorry. > The short answer is, please don't commit this just yet. I have no intention to. (Except locally. Muhahaha! :-) > The purpose of this message is to (try to) solicit input from folks. > Note also that while there are two copies of in_h_gr_, > there's no problem with them as the mode distinguishes them. Sorry, I think you're missing the point: I want to get the register accesses through to the model machinery. > So another way to look at the bug (no claim is made that this > isn't obvious) is that the two copies of `in_sr' are ok except > that one or both should include a mode so there's no compilation error. > > Clearly that's what's already happening with in_h_gr_. > No claim is also made that this is a better way to look at the bug. > Maybe it is, maybe it isn't. It comes down to "what do we want?". No no no. Not a copy for each accessed mode, please. Please don't do that. For one, how would you map that on the model machinery? How you you send this to the unit function in: (unit u-foo "Foo Unit" () 1 1 () ((dr INT -1)) () ())) Consider the case where one insn accesses a register in multiple modes, while another accesses it in one mode. > We should also look at the effect on opcodes/m32r-opinst.c. > The salient change here is: > > @@ -202,6 +202,16 @@ static const CGEN_OPINST sfmt_cmpz_ops[] > Is the mode relevant here? What do you think? I don't claim to know my way around the CGEN assembler/opcode parts, except as I told previously, that the assembler parts should obviously *not* be affected by anything in the semantics. It should only look at the (+ OP1_9 OP2_0 dr sr (f-simm16 0)) (heh, cute, looks like a curse :-) format line. > IIRC, way back when, I wanted the mode to be relevant, > it was (at the time) useful information. > > Plus, for architectures where the set of a register in different modes > has different effects on the register (e.g. x86, m68k), > the mode is important. The x86 also has to deal with > ah,bh,etc. I'm using this in a related situation, actually. > where there's no current mode one can apply to eax,ebx,etc. and get the > intended meaning. So do we outlaw such things and say > registers can only be set in their natural mode, and for x86,m68k,etc. > we create additional registers that alias the appropriate bits of the > "real" register? Does the patch have this "outlawing" effect? I didn't intend that. > Or do we attach meaning to setting a register in > a mode different than its natural mode? Like what? (Except for the obvious: affecting only the part of the register corresponding to the mode. I did not intend to change this.) > [for x86 and ah,bh,etc. we can still go the latter way and either > create new modes (blech (*1)) or define aliases] No new modes or aliases, please. > I've started to come up with a patch that allows us to retain the mode > of the use, rather than always using the natural mode, should we want to go > this route. I think we do. And the model thingy? That's the one thing that's important to me. brgds, H-P