From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27889 invoked by alias); 3 Dec 2004 02:08:33 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 27829 invoked from network); 3 Dec 2004 02:08:22 -0000 Received: from unknown (HELO krynn.se.axis.com) (212.209.10.221) by sourceware.org with SMTP; 3 Dec 2004 02:08:22 -0000 Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.83.5.18]) by krynn.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id iB328EAD001618; Fri, 3 Dec 2004 03:08:14 +0100 Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id iB328EdD015416; Fri, 3 Dec 2004 03:08:14 +0100 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id iB328DUr015412; Fri, 3 Dec 2004 03:08:13 +0100 Date: Fri, 03 Dec 2004 02:08:00 -0000 Message-Id: <200412030208.iB328DUr015412@ignucius.se.axis.com> From: Hans-Peter Nilsson To: fche@redhat.com CC: hans-peter.nilsson@axis.com, cgen@sources.redhat.com, sid@sources.redhat.com In-reply-to: <20041203004646.GL15612@redhat.com> (fche@redhat.com) Subject: Re: Committed: src/cpu/cris.cpu, intended for src/sim/ src/sid/component/cgen-cpu/ but some problems X-SW-Source: 2004-q4/txt/msg00017.txt.bz2 > Date: Thu, 2 Dec 2004 19:46:46 -0500 > From: "Frank Ch. Eigler" > Plus sid is not as well known, and some people have expressed > reservations about Red Hat retaining its copyright over the > core of the software. BTW, we'll have to resolve the copyright issue for the CRISv32 sid port and assorted components to be merged. For all I know (and I should know) Axis is happy with the current license terms (GPL but allowing binary distributions IIRC), but we do not want to assign copyright for them to Red Hat. (To FSF is ok). Is there a defined path for contributing to SID without copyright assignment to Red Hat? Can this be solved? (I thought such a path was in progress of being defined a year ago or so, or sid copyright assigned to the FSF or suchlike.) > We have a really wild sid port (MeP) that does model the pipeline > in much the same way that the sim/common/cgen* stuff does (and goes > way beyond in some other ways), and I believe this does not rely on > any sid/cgen infrastructure not already public. Cool. Want that! Will put on my TODO list to investigate. Hints welcome. > > [...] > > Processing extractor fn bodies ... > > Processing extractor for "#f" ... > > Processing extractor for "(#f 16 (f-operand2 #) (f-operand1 #) (-nosan-= > Rs SI) (-nosan- f-operand2 UINT) (-nosan- h-raw-gr-SI-index-of--DFLT-Rd SI= > ) (-nosan- xbit BI) (-nosan- zbit BI cond) (-nosan- cbit-move BI) (-nosan-= > h-gr-SI-index-of--DFLT-Rd SI) (-nosan- nbit BI) (-nosan- prefix-set BI) (-= > nosan- vbit-move BI) (-nosan- xbit BI) (-nosan- zbit BI) )" ... > > [...] > > This doesn't ring a big bell, so I'd have to sit down and debug cgen > for real to see what's happening. Thanks for looking into it. > (And "debugging cgen" to me has > simply meant the scheme equivalent of inserting printfs.) Bummer. > One oddity > to keep in mind though: ifield extractors are very limited in terms > of what sorts of RTL constructs they can safely contain, but this > limitation is not enforced properly. (It comes from a poor definition > of execution context for these bad boys, in that they have to expand > somehow both within bfd and within sim/sid.) I *have* had problems with ifields and its setters/getters, but not recently IIRC. The more recent problem was that they don't like ISA attributes, or something to that effect. (I had problems with mostly-same define-hardware variants for different MACH until I realized the totally orthogonal requirement for that case of having different names but same semantic-name! Nothing like fading memories of horrible debug sessions and wild goose chases! :-) Still, I see similar output happening for sim; (cgen-decode.c), but of course there everything works, so I have reasons to believe cris.cpu is at least *mostly* correct. ;-) Anyway, I tried deleting everything except the first register-register move insn (after "nop" ;-) (i.e. from line 1955 and below) and still get the same error with cgen-decode.cxx. Neither that insn nor nop use any strange (multi-)ifields AFAICT. brgds, H-P