From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10386 invoked by alias); 13 Feb 2004 19:17:04 -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 10106 invoked from network); 13 Feb 2004 19:17:03 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Feb 2004 19:17:03 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i1DJH2b04598 for ; Fri, 13 Feb 2004 14:17:02 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i1DJH0M14104; Fri, 13 Feb 2004 14:17:00 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i1DJGxX03680; Fri, 13 Feb 2004 11:16:59 -0800 Message-ID: <402D22AB.4020804@redhat.com> Date: Fri, 13 Feb 2004 19:17:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 MIME-Version: 1.0 To: Joern Rennecke CC: Joern Rennecke , gdb-patches@sources.redhat.com Subject: Re: [RFA] sh-sim loose ends References: <200402131229.i1DCTHN16278@linsvr1.uk.superh.com> In-Reply-To: <200402131229.i1DCTHN16278@linsvr1.uk.superh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00350.txt.bz2 Joern Rennecke wrote: >>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. OK, I'll drop those. I assume the others are OK?