:Luigi Rizzo <lu...@labinfo.iet.unipi.it>
:>not speaking about vinum, but to me, the indentation of 8 char and
:...
:
:According to most of the coding standards I've read, readability
:(and hence maintainability) come before efficiency. That said, I
:agree that efficiency _is_ an issue within the kernel's critical
:paths (the TCP/IP code being one).
:
:Judicious use of inline functions (and macros) should help move
:code to the left - and may even make it more understandable.
:
:Peter
More then judicious use -- inlines are an incredible advantage. Most
people don't realize that GCC will optimize constant arguments through
an inline call. Try this:
static __inline
fubar(int c)
{
if (c & 1)
++c;
if (c & 2)
++c;
return(c);
}
void
fubar2(void)
{
volatile int x;
x = fubar(0);
x = fubar(1);
x = fubar(2);
x = fubar(3);
}
% cc -S -O2 x.c
% cat x.s
fubar2:
pushl %ebp
movl %esp,%ebp
subl $4,%esp
xorl %eax,%eax <----- fubar (0)
movl %eax,-4(%ebp)
movl $3,-4(%ebp) <----- fubar (1)
movl $3,-4(%ebp) <----- fubar (2)
movl $4,-4(%ebp) <----- fubar (3)
leave
ret
For some good examples of inlines and inherent optimizeable code,
take a look at vm/vm_page.h.
For example, look at vm_page_sleep_busy() keeping in mind that the
also_m_busy and msg arguments are usually constants.
Another example: vm_page_protect(), where 'prot' is usually passed
as a constant.
For that matter, we could probably inline a good chunk of the smaller
pmap_*() functions as well, such as pmap_page_protect ( currently in
i386/i386/pmap.c ). This would get rid of an entire subroutine call
layer without reducing readability at all.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
