looking at a high resolution clock for each of the following events:
function call, function return, interrupt entry, interrupt exit,
and interesting branches. The differences between the times of
these events are added at appropriate places in a ordinary histogram
(as if very fast statistical profiling sampled the pc at those
places) so that ordinary gprof can be used to analyze the times.
gmon.h:
Histogram counters need to be 4 bytes for microsecond resolutions.
They will need to be larger for the 586 clock.
The comments were vax-centric and wrong even on vaxes. Does anyone
disagree?
gprof4.c:
The standard gprof should support counters of all integral sizes
and the size of the counter should be in the gmon header. This
hack will do until then. (Use gprof4 -u to examine the results
of non-statistical profiling.)
config/*:
Non-statistical profiling is configured with `config -pp'.
`config -p' still gives ordinary profiling.
kgmon/*:
Non-statistical profiling is enabled with `kgmon -B'. `kgmon -b'
still enables ordinary profiling (and distables non-statistical
profiling) if non-statistical profiling is configured.
libkern.a are now specified by listing their source files in
files.${MACHINE}. The list is machine-dependent to save space.
All the necessary object for each machine must be linked into the
kernel in case an lkm wants one.
(on an i486, 10 cycles (+ cache misses) instead of 15). The
change should be a no-op if the compiler is any good. The best
possible i*86 code for the same algorithm is only 1 more cycle
faster on i486's so I don't want to bother implementing an
assembler version.
scanc() is a bottleneck for OPOST processing. It is naturally
about 4 times as slow as bcopy() on 32-bit systems.
I couldn't find a better way to avoid compiler warnings about
redundant and/or inconsistent declaration of ffs(). I'd like to
be able to declare prototypes in general headers without committing
to implementing them as `static inline' or `extern', but there
seems to be no way to do this with gcc-2.6.1. E.g.,
int foo(void);
static __inline int foo(void) { return 1; }
causes a warning about the linkage mismatch, while the opposite
order causes a warning about the redundant declaration.
that add it too, and end up fighting an unwanted battle right now,
I'm just going to back away from both and start including my own private
copies of everything. I'm not going to use _anything_ from libkern
until we decide its fate.
I just know I'm going to get flamed for adding for the miserable
abortion that is libkern, but what am I supposed to do? At least I
didn't drag in the ctype stuff! :-)
"gcc -Wstrict-prototypes" doesn't emit warnings about them.
Write each min/max functions on a single line so that the similarity and
triviality of the functions is more obvious.
Put the quad min/max functions in the correct place (aphabetical order).
The u_quad min/max functions are missing. Only 3 or 4 of the min/max
functions are actually used. sys/socketvar.h ``should use "lmin" but
it doesn't exist now''. lmin does exist now, but isn't used. Since we
depend on gcc for `inline', perhaps we should depend on it for __typeof
and function-expressions and use only macros min() and max() that work
for any types (I'm not sure how to handle mixed types).
