From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20039 invoked by alias); 20 Jul 2002 22:26:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20032 invoked from network); 20 Jul 2002 22:26:07 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 20 Jul 2002 22:26:07 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id CC31C5EA11; Sat, 20 Jul 2002 17:26:05 -0500 (EST) To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: WIP: Register doco References: <3D38AF69.7020902@ges.redhat.com> <3D39954D.1020306@ges.redhat.com> <3D39CAD1.3060106@ges.redhat.com> From: Jim Blandy Date: Sat, 20 Jul 2002 15:26:00 -0000 In-Reply-To: <3D39CAD1.3060106@ges.redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00213.txt.bz2 Andrew Cagney writes: > > The example of the IA-32's MMX and FP registers is a great example for > > this. The MMX registers, MM0--MM7, and the FP registers, > > ST(0)--ST(7), actually refer to the same set of eight eighty-bit > > registers, R0--R7. A reference to the floating-point register ST(i) > > becomes a reference to R((TOP + i) % 8), where TOP is a three-bit > > field in the FPU status register. But a reference to the MMX register > > MM(i) becomes a reference to the lower 64 bits of R(i) (which would be > > the mantissa of some ST(i)). > > (In the current code, ST(I) and not R(I) is stored, so we end up with > MM(I) == regcache(FP0 + (TOP + 1) % 8) :-( I'm almost ready to dust > off the patch that does this.) > > Anyway, I think the above example highlights why I see it as important > to use terms like ``hardware'' or even ``physical''. Those terms drag > the GDB developer's eye away from those glossy user level ISA specs, > and instead focuses their attention on the underlying hardware model > used to implement the userland ISA. While well above the level of > flip-flops, it is still a clear step below the ISA that a typical > native GDB user will be aware of. (A PPC refers to the ``operating > environment architecture''). > > For the i387, the programmer spec is all about a register stack, yet > the underlying hardware uses a block of 8 registers and an index. It > is the latter, the lower level hardware details, that the GDB > developer should focus their attention on when deciding the contents > of a register cache. No, I think we need to draw the GDB developer's eye *to* those glossy user-level ISA specs. :) Figure 8-1 --- the first diagram in the chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right there. The second diagram, figure 8-2, shows how the TOP field affects the relationship between ST(i) and Ri. The fact that there is a fixed set of registers accessed as a rotating stack is very much part of the ISA documentation. The chapter on MMX also gives the gorey details about how the aliasing works. It's not just for gee-whiz value --- you have to know this stuff in order to write code which does both floating-point and MMX operations. Every MMX instruction sets the FPU's TOP field to zero, for example. As a sanity check, assuming that SPARC register windows are analogous: the SPARC ISA spec talks about register windows immediately, as well. Figure 2 in the chapter on Registers shows "Three Overlapping Windows and the Eight Global Registers". (For some reason, that makes me think of Goldilocks and the Three Bears.) So in both cases, these underlying structures are explicitly part of the ISA. The distinctions can be made clearly without going beyond the ISA. We don't need to resort to non-distinctions like "hardware register" to make our point. In cases like this one, where we're trying to draw a distinction (between "cooked" and "raw" registers) whose exact meaning varies from one architecture to the next, there is no way to really define what you mean: each person doing a GDB port needs to get the gist of the distinction, and see how it might help them best describe their architecture to GDB. The best way to do that is with a series of examples showing how it applies to existing, well-known architectures. I'd be happy to contribute text for those examples, if you agree they would be useful. At this point I've dug out the relevant parts of my IA-32, SPARC, and IA-64 ISA manuals anyway. :)