From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Albert Veli Newsgroups: gmane.emacs.devel Subject: Re: Suggestion for gdb-ui.el Date: Wed, 01 Jun 2005 10:02:37 +0200 Message-ID: <1117612957.16251.79.camel@localhost.localdomain> References: <1117534403.15206.4.camel@localhost.localdomain> <17052.55784.138439.629172@farnswood.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1117613905 13076 80.91.229.2 (1 Jun 2005 08:18:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 1 Jun 2005 08:18:25 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 01 10:18:14 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DdOOq-0004P4-27 for ged-emacs-devel@m.gmane.org; Wed, 01 Jun 2005 10:16:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DdOU4-0001IG-SR for ged-emacs-devel@m.gmane.org; Wed, 01 Jun 2005 04:21:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DdOIb-0007cB-0B for emacs-devel@gnu.org; Wed, 01 Jun 2005 04:10:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DdOIW-0007bX-TN for emacs-devel@gnu.org; Wed, 01 Jun 2005 04:09:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DdOFK-0007F9-7d for emacs-devel@gnu.org; Wed, 01 Jun 2005 04:06:38 -0400 Original-Received: from [80.252.161.130] (helo=biosensor01.BIOSENS.LOCAL) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DdODP-0001Cq-7N for emacs-devel@gnu.org; Wed, 01 Jun 2005 04:04:39 -0400 Original-Received: from 192.168.60.1 ([192.168.60.1]) by biosensor01.BIOSENS.LOCAL ([192.168.60.2]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jun 2005 08:02:31 +0000 Original-Received: from ubuntu01 by webmail.biosensor.se; 01 Jun 2005 10:02:38 +0200 Original-To: Nick Roberts In-Reply-To: <17052.55784.138439.629172@farnswood.snap.net.nz> X-Mailer: Evolution 2.2.1.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:37986 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37986 Hi Nick! > > * Suggestion: Update lisp/progmodes/gdb-ui.el so the *registers* buffer > > somehow remembers the line number and scrolls back to the same line > > after updating the registers. > > The code was meant to do this but didn't because of an issue with point > and window point. If you update from the repository this should work now. Yes it works now. Great! > > > It would also be nice if the changed registers would be highlighted > > somehow (I noticed it's on the TODO list in gdb-ui.el). > > This shouldn't be too hard to do with the GDB/MI commands. I have other > changes that also use GDB/MI but I am waiting till after the release before > installing them in case such changes introduce bugs. How useful is this > feature? I've not done low-level debugging or watched the contents of the > registers. What debugging situations require this? Are you debugging a > disassembly view in GDB from C code, or assembler (either generated by the > compiler or hand written) directly. If you write hand-written inline assembly then it is very useful to see the registers while debugging. While doing calculations in assembly you often try to put as many variables as possible into registers and try not to load/store more than necessary to memory (because memory is slow). It can be helpful to see which registers have changed if you, for instance, write an inline asm function and want to see if it changes any registers (skip through it with next/nexti and watch the registers). If you assume registers don't change, but in reality they do change it can introduce hard-to-find(TM) bugs :) Without making a short story too long...I'm working on a program that collects and analyses measurement data from an instrument. Right now I'm investigating if it would be worth the effort to write SSE optimized routines for the analysis algorithm. It would work like this: 1. Check if the cpuid instruction is available. If not, then SSE is not available either. 2. Call cpuid and check if the SSE flag is set. 3. if (SSE is available) set function pointers to SSE optimized routines else set function pointers to C routines. An SSE optimized routine (inline gcc) could look something like this: ---8<---- ssetest.c --------- #include /* Multiply 4x4 matrix (m) by a 4x1 vector (v) * Result is a 4x1 vector (res) * * m00 m01 m02 m03 v0 * m = m10 m11 m12 m13 v = v1 * m20 m21 m22 m23 v2 * m30 m31 m32 m33 v3 * * m00*v0 + m01*v1 + m02*v2 + m03*v3 * res = m10*v0 + m11*v1 + m12*v2 + m13*v3 * m20*v0 + m21*v1 + m22*v2 + m23*v3 * m30*v0 + m31*v1 + m32*v2 + m33*v3 * * It is more efficient to send in m transposed into the inline asm code * because of the nature of the SSE instructions. * * m00 m10 m20 m30 * mt = m01 m11 m21 m31 * m02 m12 m22 m32 * m03 m13 m23 m33 */ void mul_transposed_4x4_4x1_sse(float *mt, float *v, float *res) { asm( /* Load mt into xmm0-xmm3 */ "movups (%0), %%xmm0\n\t" /* xmm0 = mt[0], mt[1], mt[2], mt[3] */ "movups 0x10(%0), %%xmm1\n\t" /* xmm1 = mt[4], mt[5], mt[6], mt[7] */ "movups 0x20(%0), %%xmm2\n\t" /* xmm2 = mt[8], mt[9], mt[10], mt[11] */ "movups 0x30(%0), %%xmm3\n\t" /* xmm3 = mt[12], mt[13], mt[14], mt[15] */ /* Load v into xmm4 */ "movups (%1), %%xmm4\n\t" /* xmm4 = v[0], v[1], v[2], v[3] */ /* Now multiplicate mt by v */ /* xmm5 = v[3], v[3], v[3], v[3] */ "movaps %%xmm4, %%xmm5\n\t" "shufps $0xff, %%xmm5, %%xmm5\n\t" "mulps %%xmm5, %%xmm3\n\t" /* xmm3 = mt[12]*v[3], mt[13]*v[3], mt[14]*v[3], mt[15]*v[3] */ /* xmm5 = v[2], v[2], v[2], v[2] */ "movaps %%xmm4, %%xmm5\n\t" "shufps $0xaa, %%xmm5, %%xmm5\n\t" "mulps %%xmm5, %%xmm2\n\t" /* xmm2 = mt[8]*v[2], mt[9]*v[2], mt[10]*v[2], mt[11]*v[2] */ /* xmm5 = v[1], v[1], v[1], v[1] */ "movaps %%xmm4, %%xmm5\n\t" "shufps $0x55, %%xmm5, %%xmm5\n\t" "mulps %%xmm5, %%xmm1\n\t" /* xmm1 = mt[4]*v[1], mt[5]*v[1], mt[6]*v[1], mt[7]*v[1] */ /* xmm4 = v[0], v[0], v[0], v[0] */ "shufps $0x00, %%xmm4, %%xmm4\n\t" "mulps %%xmm4, %%xmm0\n\t" /* xmm0 = mt[0]*v[0], mt[1]*v[0], mt[2]*v[0], mt[3]*v[0] */ /* Add it up in xmm0 */ "addps %%xmm1, %%xmm0\n\t" /* xmm0 = mt[0] * v[0] + mt[4] * v[1], mt[1] * v[0] + mt[5] * v[1], * mt[2] * v[0] + mt[6] * v[1], mt[3] * v[0] + mt[7] * v[1] */ "addps %%xmm3, %%xmm2\n\t" /* xmm2 = mt[8] * v[2] + mt[12] * v[3], mt[9] * v[2] + mt[13] * v[3], * mt[10] * v[2] + mt[14] * v[3], mt[11] * v[2] + mt[15] * v[3] */ "addps %%xmm2, %%xmm0\n\t" /* xmm0 = mt[0]*v[0] + mt[4]*v[1] + mt[8]*v[2] + mt[12]*v[3], * mt[1]*v[0] + mt[5]*v[1] + mt[9]*v[2] + mt[13]*v[3], * mt[2]*v[0] + mt[6]*v[1] + mt[10]*v[2] + mt[14]*v[3], * mt[3]*v[0] + mt[7]*v[1] + mt[11]*v[2] + mt[15]*v[3] */ /* Move result to res */ "movups %%xmm0, (%2)\n\t" : /* No output */ : "r"(mt), "r"(v), "r"(res) /* Input: mt=%0, v=%1, res=%2 */ /* clobbered: xmm0-xmm5 and memory (in *res) */ : "%xmm0", "%xmm1", "%xmm2", "%xmm3", "%xmm4", "%xmm5", "memory"); } int main(void) { float res[4]; float mt[16] = { 0.0f, 4.0f, 8.0f, 12.0f, 1.0f, 5.0f, 9.0f, 13.0f, 2.0f, 6.0f, 10.0f, 14.0f, 3.0f, 7.0f, 11.0f, 15.0f }; float v[4] = { 0.0f, 1.0f, 2.0f, 3.0f }; /* Add code to check for SSE here */ mul_transposed_4x4_4x1_sse(mt, v, res); /* Print out res vec. Should be * 0*0 + 1*1 + 2*2 + 3*3 = 14 * 4*0 + 5*1 + 6*2 + 7*3 = 38 * 8*0 + 9*1 + 10*2 + 11*3 = 62 * 12*0 + 13*1 + 14*2 + 15*3 = 86 */ printf("%.1f, %.1f, %.1f, %.1f\n", res[0], res[1], res[2], res[3]); return 0; } --------- ssetest.c --->8---- Note that the code above don't call cpuid. You must have SSE to try it out in gdb-ui (processor >= Intel Pentium3 || processor >= AMD Athlon XP). On GNU/Linux you can check the output of 'cat /proc/cpuinfo | grep ^flags' to see if sse is there. For details about cpuid, check out the "Basic Architecture" manual chapter 14, available here: http://developer.intel.com/design/pentium4/manuals/index_new.htm Regards, Albert