From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28265 invoked by alias); 18 Mar 2004 21:02:47 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 28209 invoked from network); 18 Mar 2004 21:02:46 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 18 Mar 2004 21:02:46 -0000 Received: from redhat.com (to-dhcp15.toronto.redhat.com [172.16.14.115]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 63E7B8000DA; Thu, 18 Mar 2004 16:02:46 -0500 (EST) Message-ID: <405A0E73.5040500@redhat.com> Date: Thu, 18 Mar 2004 21:02:00 -0000 From: Dave Brolley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: "Frank Ch. Eigler" Cc: sid@sources.redhat.com, cgen@sources.redhat.com Subject: Re: [patch][rfa] SID --trace-semantics output References: <4059F6DD.4090407@redhat.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-q1/txt/msg00042.txt.bz2 Frank Ch. Eigler wrote: >brolley wrote: > > > >>A client of ours, for whom we're developing a SID port, requested >>that SID's semantic trace show the actual value stored, accounting >>for read-only fields and other side effects, rather than showing the >>value which was attempted to be stored. [...] >> >> > >Especially for bits outside the CPU, this has the potential to >mislead, in that the disassembly trace would not represent the actions >of the CPU. > but it would represent the actual result of the operation, which is what they want. Makes sense to me too, FWIW. >>I eventually came up with the notion that the write/set methods of >>SID's busses, control registers, memory access methods and hardware >>write handers could return the actual value written. [...] >> >> > >I am quite unfond of this approach. It is a messy and limited way of >providing just one more level of tracing. Have you considered instead >of all this the addition of tracing flags in the various devices that >thusly mutilate their data? That way, when they detect an incoming >write (from whatever source), they can print the final afterimage. >With carefully arranged tracing code in cgen_cpu, the additional >messages from those peripherals could appear properly intermingled. > > This idea sounds reasonable and more in line with the SID architecture. I should have asked before I leaped :-) Thanks, Dave