- Use explicit assembly; don't want the compiler optimizing things too
much here.
- Subtract 2 for each iteration of the loop, rather than 3. The loop
consists of only 2 instructions (even the C version compiled to a
loop of 2 instructions).
The latter change has squashed a fairly annoying timing bug in the
mii_bitbang module as used by the `ex' driver on my AlphaStation 500.
XXX delay() should maybe be rewritten again, to use the rpcc instruction.
- alpha_rpcc(), alpha_mb(), alpha_wmb() -- these are instructions, and
we win by inlining them: rpcc is generally used for profiling, and
the memory barriers really should execute as quickly as possible with
minimal side-effects (like additional loads/stores required to call the
functions!)
- alpha_pal_imb(), alpha_pal_rdps(), alpha_pal_swpipl(), alpha_pal_tbi(),
alpha_pal_whami() -- these are PALcode ops. We must specify some register
clobbers for these.
We have a very decent size savings as a result. My test system:
text data bss dec hex filename
2671724 235848 377016 3284588 321e6c /netbsd.bak
2617708 235736 377016 3230460 314afc /netbsd
Most of this comes from fewer register saves/restores around spl*() calls
(now that alpha_pal_rdps() and alpha_pal_swpipl() are inlined).
Note that alpha_pal_rdps() and alpha_pal_swpipl() remain in pal.s to
maintain binary compatibility with LKMs that may use spl*() functions.
add an IPI which causes the target CPU to perform AST processing when
it returns to userspace.
- Add a way to get/set a private pointer in the shared interrupt header.
longer need to lock the kernel pmap in pmap_kenter_pa() and pmap_kremove().
- Since locking the kernel pmap in interrupt context is no longer required,
don't go to splimp() when locking the kernel pmap.
- Implement a new pmap_remove() function, not yet enabled by default. It
is structured like pmap_protect, and should be *much* faster. This was
actually written quite some time ago, but never committed because it
didn't work properly. Given the recent bugfix to pmap_protect(), "duh,
of course it didn't work properly before...". It seems to work fine now
(have done several builds and run the UVM regression tests using the new
code), but it is currently run-time optional so that some performance
measurements can be easily run against the old and new code.
* We could overrun the eva by as much as L1SEG_SIZE-PAGE_SIZE.
* sva was advanced *twice* for each valid l3 or l2 page, causing it to get out
of sync with the PTE pointers.
remove GENERIC.v6 file (as it is part of GENERIC now).
"faith" interface is commented out by default as it is not really for
general use.
IPsec items are commented out as well, though we can enable "options IPSEC"
without export-related issue ("options IPSEC" will enable authentication
portion only). We may need to think about it again.
if you have problem compiling with INET6 on archs I do not have access to,
please contact me.
XXX what to do with arch/arm32/SHARK{,.v6}?
>split the "asc" and "tcds" searching into two separate sections and
>keep a "tcdsdev" of the booted tcds device. make sure that the "asc"
>is the child of the tcds. this fixes boot device detection on dec
>5000/400 (prolly 400-900) machines in the presense of a tcds option
>card, which would use the right tcds chip & disk scsiid of the last
>attached tcds -- which meant it would choose the wrong disk, or not
>find the boot device at all if the corresponding scsiid was unused in
>the last attached disk.
>
>XXX: this may need to be copied to dec_3000_300.c but i have no idea
>as i can not test this hardware at all...
>
>fixes PR#8771 by myself.
keep a "tcdsdev" of the booted tcds device. make sure that the "asc"
is the child of the tcds. this fixes boot device detection on dec
5000/400 (prolly 400-900) machines in the presense of a tcds option
card, which would use the right tcds chip & disk scsiid of the last
attached tcds -- which meant it would choose the wrong disk, or not
find the boot device at all if the corresponding scsiid was unused in
the last attached disk.
XXX: this may need to be copied to dec_3000_300.c but i have no idea
as i can not test this hardware at all...
fixes PR#8771 by myself.
