Re: REGISTER_IN_WINDOW_P

["David S. Miller" <davem@redhat.com>]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Tue, 23 Apr 2002 20:18:35 -0400

   > It is only referenced or set by the i960 target specific code, would
   > it be ok to remove references to it from the GDB internals
   > documentation?
   
 ...   
   you might as well, at the same time, replace the macro by a static
   function.

Done, how does this look?

2002-04-23  David S. Miller  <davem@redhat.com>

	* i960-tdep.c (register_in_window_p): New function.
	(i960_find_saved_register): Use it instead of
	REGISTER_IN_WINDOW_P.
	* config/i960/tm-i960.h (REGISTER_IN_WINDOW): Kill.

2002-04-23  David S. Miller  <davem@redhat.com>

	* gdbint.texinfo (REGISTER_IN_WINDOW): Delete definition.

--- ./config/i960/tm-i960.h.~1~	Sun Apr 21 08:52:34 2002
+++ ./config/i960/tm-i960.h	Tue Apr 23 23:25:09 2002
@@ -127,21 +127,6 @@ extern void i960_get_saved_register (cha
   i960_get_saved_register(raw_buffer, optimized, addrp, frame, regnum, lval)
 
 
-
-/* Is this register part of the register window system?  A yes answer
-   implies that 1) The name of this register will not be the same in
-   other frames, and 2) This register is automatically "saved" upon
-   subroutine calls and thus there is no need to search more than one
-   stack frame for it.
-
-   On the i960, in fact, the name of this register in another frame is
-   "mud" -- there is no overlap between the windows.  Each window is
-   simply saved into the stack (true for our purposes, after having been
-   flushed; normally they reside on-chip and are restored from on-chip
-   without ever going to memory).  */
-
-#define REGISTER_IN_WINDOW_P(regnum)	((regnum) <= R15_REGNUM)
-
 /* Number of bytes of storage in the actual machine representation
    for register N.  On the i960, all regs are 4 bytes except for floating
    point, which are 10.  NINDY only sends us 8 byte values for these,
--- ./doc/gdbint.texinfo.~1~	Sun Apr 21 18:39:54 2002
+++ ./doc/gdbint.texinfo	Tue Apr 23 23:23:39 2002
@@ -3044,11 +3044,6 @@ pointer.  It examines the current state 
 Define this if you need to supply your own definition for the function
 @code{get_saved_register}.
 
-@item REGISTER_IN_WINDOW_P (@var{regnum})
-@findex REGISTER_IN_WINDOW_P
-Define this to be an expression that is 1 if the given register is in
-the window.
-
 @item IBM6000_TARGET
 @findex IBM6000_TARGET
 Shows that we are configured for an IBM RS/6000 target.  This
--- ./i960-tdep.c.~1~	Sun Apr 21 08:19:06 2002
+++ ./i960-tdep.c	Tue Apr 23 23:25:00 2002
@@ -122,6 +122,24 @@ check_host (void)
     }
 }
 \f
+/* Is this register part of the register window system?  A yes answer
+   implies that 1) The name of this register will not be the same in
+   other frames, and 2) This register is automatically "saved" upon
+   subroutine calls and thus there is no need to search more than one
+   stack frame for it.
+
+   On the i960, in fact, the name of this register in another frame is
+   "mud" -- there is no overlap between the windows.  Each window is
+   simply saved into the stack (true for our purposes, after having been
+   flushed; normally they reside on-chip and are restored from on-chip
+   without ever going to memory).  */
+
+static int
+register_in_window_p (int regnum)
+{
+  return regnum <= R15_REGNUM;
+}
+
 /* i960_find_saved_register ()
 
    Return the address in which frame FRAME's value of register REGNUM
@@ -154,7 +172,7 @@ i960_find_saved_register (struct frame_i
      stack pointer saved for *this* frame; this is returned from the
      next frame.  */
 
-  if (REGISTER_IN_WINDOW_P (regnum))
+  if (register_in_window_p (regnum))
     {
       frame1 = get_next_frame (frame);
       if (!frame1)