From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6864 invoked by alias); 6 Feb 2004 12:39:10 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6847 invoked from network); 6 Feb 2004 12:39:08 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 6 Feb 2004 12:39:08 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by smtp.uk.superh.com (8.12.10/8.12.10) with ESMTP id i16CcXwO017667; Fri, 6 Feb 2004 12:38:34 GMT Received: from linsvr1.uk.superh.com ([192.168.16.50]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Feb 2004 12:40:00 +0000 Received: (from renneckej@localhost) by linsvr1.uk.superh.com (8.11.6/8.11.6) id i16CcWl25143; Fri, 6 Feb 2004 12:38:32 GMT From: Joern Rennecke Message-Id: <200402061238.i16CcWl25143@linsvr1.uk.superh.com> Subject: Re: [RFA] sh-sim: thislock/prevlock tweak To: msnyder@redhat.com (Michael Snyder) Date: Fri, 06 Feb 2004 12:39:00 -0000 Cc: amylaar@fairadsl.co.uk (Joern Rennecke), joern.rennecke@superh.com, gdb-patches@sources.redhat.com In-Reply-To: <4022D60A.5020905@redhat.com> from "Michael Snyder" at Feb 05, 2004 03:47:22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2004 12:40:00.0411 (UTC) FILETIME=[55C786B0:01C3ECAE] X-Scanned-By: MIMEDefang 2.39 X-SW-Source: 2004-02/txt/msg00115.txt.bz2 > Joern, > > I don't fully understand this code, but it looks to me as if this > minor change is needed. Most other instructions appear to call > the macro "L()" for the register that was explicitly the target > of the instruction. Looks sensible as far as I can see it; it would be helpful to have enough context to see the full insn. Note that L is part of the mechanism that approximates SH[123] timing; SH4 timing is entirely different. This makes a number of the MA calls rather bizarre, where we simulate the timings of a processor that doesn't implement the instructions in the first place. In October I made a patch to implement SH4 timings (controlled by an #ifdef SH4_TIMINGS), but it ended up a few percent slower than the simulator before, so I thought we should really use a simulator built with ACE_FAST for the c-torture simulator tests - even better if we can make it processor specific, i.e. no DSP insns for non-dsp processors and no FPU insns for non-fpu processors. The mere presence of the code seems to skew the memory layout and/or register allocation of the 'hot' code to make the simulator slower. So that would require to build separate binaries and a wrapper that invokes the right one, or make dejagnu pick up a specifically tuned variant. Then we had a lot of changes to the simulator for other functionality, and I didn't have the time to make this into a current patch. I'll forward a copy of my letter with the patch in case you or someone else on the list want to pick it up.