From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13941 invoked by alias); 13 Feb 2004 12:29:47 -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 13934 invoked from network); 13 Feb 2004 12:29:46 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 13 Feb 2004 12:29:46 -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 i1DCTIAA004224; Fri, 13 Feb 2004 12:29:20 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, 13 Feb 2004 12:30:47 +0000 Received: (from renneckej@localhost) by linsvr1.uk.superh.com (8.11.6/8.11.6) id i1DCTHN16278; Fri, 13 Feb 2004 12:29:17 GMT From: Joern Rennecke Message-Id: <200402131229.i1DCTHN16278@linsvr1.uk.superh.com> Subject: Re: [RFA] sh-sim loose ends To: msnyder@redhat.com (Michael Snyder) Date: Fri, 13 Feb 2004 12:29:00 -0000 Cc: joern.rennecke@superh.com (Joern Rennecke), amylaar@fairadsl.co.uk (Joern Rennecke), gdb-patches@sources.redhat.com In-Reply-To: <402C11C6.1090404@redhat.com> from "Michael Snyder" at Feb 12, 2004 03:52:38 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 12:30:47.0975 (UTC) FILETIME=[3564BB70:01C3F22D] X-Scanned-By: MIMEDefang 2.39 X-SW-Source: 2004-02/txt/msg00337.txt.bz2 > Hmmm? I thought 'L' was for registers, and 'MA' was for memory access. > This is the only instruction that modifies a gpr but doesn't call 'L'. > Figured it was an oversight. No, MA is for the memory *access conflict* between data access and instruction fetch for the non/unified cache SH[123], while L is for the memory access *latency* on SH[123]. And, of course, there is also no L for "mov ,". > Actually I was just going for consistancy (everywhere else that > modifies nip uses SET_NIP). I'll gladly drop this part of the > patch if you don't like it. Well, I don't like it because it adds more code unnecessarily, thus increasing the working set. And it isn't really inconsistent; SET_NIP is used when nip is changed for something other than linear instruction fetch, so that we know if we'll sooner hit a loop boundary or the end of memory. ppi_insn and the profile trap just do linear instruction fetch for larger instructions; sleep / trap 0xc3 re-fetches the same instruction again.