From owner-freebsd-hackers  Sat Oct 21 16:56:22 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id QAA17610
          for hackers-outgoing; Sat, 21 Oct 1995 16:56:22 -0700
Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA17579
          for <hackers@freebsd.org>; Sat, 21 Oct 1995 16:56:11 -0700
Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id QAA00601; Sat, 21 Oct 1995 16:54:53 -0700
Message-Id: <199510212354.QAA00601@precipice.shockwave.com>
To: Steven Wallace <swallace@ece.uci.edu>
cc: Bruce Evans <bde@freefall.freebsd.org>, CVS-commiters@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org, hackers@freebsd.org
Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] 
In-reply-to: Your message of "Sat, 21 Oct 1995 16:04:00 PDT."
             <199510212304.QAA06180@newport.ece.uci.edu> 
Date: Sat, 21 Oct 1995 16:54:51 -0700
From: Paul Traina <pst@shockwave.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk


  From: Steven Wallace <swallace@ece.uci.edu>
  Subject: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c s
>>ysv_shm.c]

  >   which passes the args correctly (as void *).  Then we need to handle
  >   varargs functions and struct padding better.  I think all the details
  >   can be hidden in machine-generated functions so that the args structs
  >   and verbose macros to reference them don't have to appear in the core
  >   sources.
  I agree. I don't like SCARG references all over the place.
  I take it you are refering to your static inline idea.  Why don't
  we just go for that?  Or should we do something like my example
  in the interim?

This brings up a point I wanted to mention...

While I realize this is a bit against the philosophy that some of the
team members hold,  which is that we should not rely on gcc-type
functionality, I'd actually prefer to see things like SCARG and
prototype-glue done as static inlines where appropriate.  The reason
being is that with a static inline, as you can enforce type checking
with:

	static inline struct rntype *
	rt2rn (struct rttype *rt)
	{
		return (rntype *) rt;
	}

as opposed to

	#define RT2RN(x) ((rntype *) (x))

I don't like relying on gcc,  but if I wanted to draw a line in the sand,
I'd much prefer to draw a line based upon gcc than pcc.  The idea that folks
are even still today coding variables with the 'register' tag* and trying to
hand-optimize register utilization by re-using symbols** instead of letting
the compiler do that sort of thing (it's almost always better than us) is
pretty silly.

Just a random comment prompted by this discussion.

Paul


* every time you use the register tag, your're strongly encouraging
  gcc to reserve a register for use by that variable.  gcc, unlike pcc,
  already understands when it should and shouldn't use registers and
  can do this far better than we can,  so it's a bad idea to hamstring
  gcc by stealing its registers away...if something should be kept in
  a register, it will be kept there

**e.g: radix.c (I know, not out fault)

   register int temp_integer;

   temp_integer = foo << 3 + bar;
   y = temp_integer * something else;

   .
   .
   .

   temp_integer = bzork * fnord;
   temp_integer = temp_integer << gazook;

   instead of:

   int middle, end;

   middle = foo << 3 + bar;
   y = middle * something else;
   .
   .
   .
   end = bzork * fnord;
   end = end << gazook;

   In the later case, gcc is smart enough to allocate register storage
   for middle and end, when they are needed, but can free up that
   register for use elsewhere between those two sections of code.
   Not to mention that you can then used "useful" names instead of
   x, y, and/or temp. :-)