From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30654 invoked by alias); 14 Mar 2006 22:04:35 -0000 Received: (qmail 30590 invoked by uid 22791); 14 Mar 2006 22:04:32 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Mar 2006 22:04:31 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k2EM4Sqv001383; Tue, 14 Mar 2006 17:04:28 -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 k2EM4R115958; Tue, 14 Mar 2006 17:04:27 -0500 Received: from [172.16.14.227] (IDENT:CLQ6prwKfDiaDgfge2PTMOyxwQ44tLQM@topaz.toronto.redhat.com [172.16.14.227]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k2EM4QxX002036; Tue, 14 Mar 2006 17:04:27 -0500 Message-ID: <44173DEA.6080906@redhat.com> Date: Tue, 14 Mar 2006 22:04:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) MIME-Version: 1.0 To: Hans-Peter Nilsson CC: fche@redhat.com, cgen@sourceware.org Subject: Re: [RFA:] Fix breakage of manually building SID CPU References: <200603142124.k2ELObJ9011226@ignucius.se.axis.com> In-Reply-To: <200603142124.k2ELObJ9011226@ignucius.se.axis.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-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00022.txt.bz2 Hans-Peter Nilsson wrote: >>Date: Tue, 14 Mar 2006 12:16:55 -0500 >>From: "Frank Ch. Eigler" >> >> >>I believe (delay) was never implemented properly for the SIM backend, >>only for SID. I expect it to be treated rather like a no-op for SIM, >>or equivalently, that any SIM-targeting .cpu users of (delay) should >>work just as well without. >> >> > >Um, what (delay) are you referring to above? >A (delay 1 (set pc something)) certainly is different >to (set pc something). > >I now think it's the cris.cpu pc setter function that may have >something that causes the SID cgen-cpu generators to barf. > > > (delay 1 (set pc something)) was already implemented and working for SIM (fr30 uses it). It appears that (set (delay 1 pc) something) was only implemtned for SID. Furthermore, SIM now only accepts the former and SID only accepts the latter, making it difficult (impossible?) to share a .cpu file for both back ends. Dave