From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15285 invoked by alias); 3 Dec 2004 00:46:55 -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 15234 invoked from network); 3 Dec 2004 00:46:48 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 Dec 2004 00:46:48 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB30kmuq019234; Thu, 2 Dec 2004 19:46:48 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB30klr15891; Thu, 2 Dec 2004 19:46:47 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id iB30kloS003494; Thu, 2 Dec 2004 19:46:47 -0500 Received: from tooth.toronto.redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 4D3DE80035F; Thu, 2 Dec 2004 19:46:47 -0500 (EST) Received: from tooth.toronto.redhat.com (IDENT:jDvJSh+OQKmsBFi4lziCqDvlUck+lIHJ@localhost [127.0.0.1]) by tooth.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id iB30kldS031320; Thu, 2 Dec 2004 19:46:47 -0500 Received: (from fche@localhost) by tooth.toronto.redhat.com (8.12.8/8.12.8/Submit) id iB30kkKX031318; Thu, 2 Dec 2004 19:46:46 -0500 Date: Fri, 03 Dec 2004 00:46:00 -0000 From: "Frank Ch. Eigler" To: Hans-Peter Nilsson Cc: cgen@sources.redhat.com, sid@sources.redhat.com Subject: Re: Committed: src/cpu/cris.cpu, intended for src/sim/ src/sid/component/cgen-cpu/ but some problems Message-ID: <20041203004646.GL15612@redhat.com> References: <200411291202.iATC2QGJ011968@ignucius.se.axis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DfnuYBTqzt7sVGu3" Content-Disposition: inline In-Reply-To: <200411291202.iATC2QGJ011968@ignucius.se.axis.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-q4/txt/msg00016.txt.bz2 --DfnuYBTqzt7sVGu3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1966 Hi, HP - On Mon, Nov 29, 2004 at 01:02:26PM +0100, Hans-Peter Nilsson wrote: > [...] > With SID, a complete system boots and runs Linux on CRISv32.=20=20 Wow. > Considering that both SID and sim work as dejagnu baseboards (at > least by brief inspection of dejagnu), why have both? Well, sim > is the snap-in-simulator of choice for GCC testing (my main > purpose for it) and asking people to build SID instead is a > obstacle.=20=20 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. > Also, at the time I wrote it (perhaps still the case), I couldn't > find a way to model cycle-correctness for the SID simulator. 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. =20 > [...] > 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. (And "debugging cgen" to me has simply meant the scheme equivalent of inserting printfs.) 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.) - FChE --DfnuYBTqzt7sVGu3 Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFBr7d2VZbdDOm/ZT0RAmMKAJ9mbct7OkCHnUL8oY/UVGQzftefdgCghB4T 45xP4cZbRoTjsy9Q2ZPhVTk= =ugsR -----END PGP SIGNATURE----- --DfnuYBTqzt7sVGu3--