Date: Sat, 21 Oct 1995 16:54:51 -0700 From: Paul Traina <pst@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] Message-ID: <199510212354.QAA00601@precipice.shockwave.com> In-Reply-To: Your message of "Sat, 21 Oct 1995 16:04:00 PDT." <199510212304.QAA06180@newport.ece.uci.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510212354.QAA00601>