From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24683 invoked by alias); 16 Jan 2004 21:11:17 -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 24676 invoked from network); 16 Jan 2004 21:11:17 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 16 Jan 2004 21:11:17 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA27943; Fri, 16 Jan 2004 13:11:05 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma027916; Fri, 16 Jan 04 13:10:59 -0800 Received: from claire.transmeta.com (claire.transmeta.com [10.10.25.31]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id i0GLB3f29887; Fri, 16 Jan 2004 13:11:03 -0800 (PST) Received: (from dje@localhost) by claire.transmeta.com (8.11.6/8.11.6) id i0GLB3i05246; Fri, 16 Jan 2004 13:11:03 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16392.21351.39235.645495@claire.transmeta.com> Date: Fri, 16 Jan 2004 21:11:00 -0000 To: Kazuhiro Inaoka Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [PATCH] fix trap in parallel for m32r-sim In-Reply-To: <006d01c3dbf6$5edebfc0$2569910a@tool.maec.co.jp> References: <005301c3dbe1$6352c840$2569910a@tool.maec.co.jp> <16391.23988.251985.754761@claire.transmeta.com> <006d01c3dbf6$5edebfc0$2569910a@tool.maec.co.jp> X-SW-Source: 2004-01/txt/msg00423.txt.bz2 Kazuhiro Inaoka writes: > > i.e. _why_ is "trap || insn" being treated as "insn -> trap". > > If insn changes SM, IE or C flag, trap will be store wrong value. (rare > case?) I'm not sure I understand. On h/w the particular case of `trap || insn' doesn't really have parallel semantics? In general, if two insns execute in parallel and write the same resource, the result is undefined. Or does the m32r spec actually specify a well-defined answer here? > When you use "trap || insn", m32r_trap() is executed before executed insn. > A m32r_trap() uses a result of insn. Clearly for the normal case it's a bug if two insns are executing in parallel and one is able to see the result of the other. One expects all inputs to be consumed before any results are written (in general, one might certainly have special cases though). I can see that m32r_trap violates the semantics for the particular case of TRAP_SYSCALL but I'm guessing that's not at issue here. > ex) trap #2 || ldi r7,#1 > What want to do is to execute m32r_trap() after second insn. This example involves insns without overlapping resources, the insns could be executed serially in either order and the result will be the same (right?). Do you have an example where the current simulator implementation gives a different answer than h/w? > > Also, if things are indeed kosher, why the added FIXMEs? > It's meaning this patch is not enough to fix it. > I think it is a first step. What's the next step then? The FIXMEs aren't specific.