From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10609 invoked by alias); 10 Oct 2007 13:36:48 -0000 Received: (qmail 10602 invoked by uid 22791); 10 Oct 2007 13:36:47 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 Oct 2007 13:36:44 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id l9ADah98015400 for ; Wed, 10 Oct 2007 09:36:43 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9ADagSG013252; Wed, 10 Oct 2007 09:36:42 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9ADab1i022016; Wed, 10 Oct 2007 09:36:38 -0400 Message-ID: <470CD4FD.90202@redhat.com> Date: Wed, 10 Oct 2007 13:36:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Phil Muldoon CC: frysk@sourceware.org Subject: Re: frysk-core/frysk proc/BankRegister.java proc/C ... References: <20071009194630.3523.qmail@sourceware.org> <470BDF0C.5020608@redhat.com> <470C4BC2.7000306@redhat.com> <470C75FD.3080803@redhat.com> In-Reply-To: <470C75FD.3080803@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00037.txt.bz2 Phil Muldoon wrote: > Andrew Cagney wrote: >> Phil Muldoon wrote: >>> Andrew, >>> >>> I know this work is ongoing, so should I sit tight regarding the >>> FIXME notifications? I'm not sure how to fix the gpr registers >>> access. If it is work ongoing, I'll just wait until you give the >>> signal with an explanation regarding how a Task accesses it's own >>> registers. >>> >> The function to look at is Task.accessRegister(Register register,int >> offset, int length, byte[] buffer, int start, boolean write) which >> will does a direct/raw byte copy of the data into a buffer. >> >> However, yes, perhaps hold off a little until I've got all the >> register code in frysk.proc resolved. >> Andrew >> > > Ok will do, will wait and see. As a rhetorical question, what is wrong > with task.getSomeRegisterFunctionName("eax") as a general helper function? The only place where a String->Register lookup (e.g., "eax" -> frysk.isa.IA32Registers.EAX) is needed is in the expression evaluator where it interprets << $eax >>. Every where else constant object, such as frysk.isa.IA32Registers.EAX can be used: these objects are efficient (better with HashMap) and second having defined constants prevents typos such as a register being called "foo" in one place and "fos" in a second. > Why do I need to know (ptrace buffer?) offset and length to access a > register? Is this because register access is being move to the task > from the ISA? Just trying to get a sense of where this refactor is going. > I'm not sure what you mean, the offset/length are for within the specified register, and start is an offset into the byte buffer. Two things change: tThe code that implements register accesses isn't being moved to the task; but the way to access registers is now simpler, contrast: Task.getRegister(IA32Register.XIP) with: Task.getIsa().getBankRegister("xip").getRegister(task) the internals, though cleaned up will still be very similar. Andrew > Regards > > Phil >