src/sys/alpha/include/atomic.h, branch releng/5.3

MFC:

2004-09-13T21:52:04Z

revision 1.19 date: 2004/09/10 05:00:27; author: marcel; state: Exp; lines: +14 -62 The previous commit, roughly one and a half years ago removed the branch prediction optimization for LINT, because the kernel was too large. This commit now removes it altogether since it causes build failures for GENERIC kernels and the various applicable trends are such that one can expect that it these failure will cause more problems than they're worth in the future. These trends include: 1. Alpha was demoted from tier 1 to tier 2 due to lack of active support. The number of people willing to fix build breakages is not likely to increase and those developers that do have the gumption to test MI changes on alpha are not likely to spend time fixing unexpected build failures first. 2. The kernel will only increase in size. Even though stripped-down kernels do link without problems now, compiler optimizations (like inlining) and new (non-optional) functionality will likely cause stripped-down kernels to break in the future as well. So, with my asbestos suit on, get rid of potential problems before they happen. Approved by: re (scottl)

Workaround for compiling LINT. Large kernels (like LINT) can have

2003-02-23T06:34:21Z

branch targets that are too far apart for the BRADDR relocation. This is caused by the branch prediction optimizationi in the atomic inlines here, because they jump across sections. The workaround is to suppress jumping to a different section when compiling LINT. To generate correct code in that case, the section directives are replaced by a branch and a label to deal with the fall-through case. Reasonably good C compilers will optimize this away anyway, so the end result isn't really that bad.

Remove extranious memory barriers, and correct the placement of a few others.

2002-10-30T01:41:44Z

This provides a 30% reduction in system time and a 6% reduction in wallclock time for a make buildworld on my xp1000 (one 21264). FWIW, I've been running this for nearly 2 months without problems. Portions submitted by: ticso, jhb Tested by: jhb (ds20 dual 21264)

Use the newer "+" modifier on output contraints when a register or

2002-10-25T20:22:12Z

memory datum is used for both input and output instead of using matching constraints.

Wrap GNUish asm() code in #ifdef GNUC

2002-09-21T19:12:59Z

- Apparently, the Alpha ABI mandates that arguments be passed sign-extended

2002-05-17T05:45:39Z

regardless of if they are signed or unsigned since it is easier to work with sign-extended values. Thus, remove the disabled zapnot to zero-extend the sign-extended value we read from *p in atomic_cmpset_32() since the cmpval we are comparing against should already be sign-extended. - To ensure that the compiler knows to sign-extend the upper 32 bits of cmpval rather than leaving garbage in there, cast the appropriately in the constraints section. Help from: Richard Henderson

Temporarily disable Jeff's fix for atomic_cmpset_32() to zero-extend the

2002-05-11T04:27:39Z

value we load from memory. gcc3.1 passes in the u_int32_t old value to compare against as a _sign_-extended 64-bit value for some reason (bug?). This is a temporary workaround so kernels work again on alpha.

zapnot the signed bits in atomic_cmpset_32. Previously this did not work with

2002-05-08T05:19:56Z

negative values because the original value was sign extended but the compared value was not.

Be conservative and always perform an mb after an atomic_cmpset operation.

2001-06-22T21:13:20Z

- Fix memory barriers in atomic operations so that the barriers are always

2001-04-17T02:50:05Z

"inside" of locked regions. That is, an acquire atomic operation will always enforce a memory barrier after the atomic operation and a release operation will always enforce a memory barrier before the atomic operation. - Explicitly use 'mb' instead of 'wmb' in release atomic operations. The 'wmb' memory barrier is not strong enough to guarantee coherence with other processors. This is effectively a nop since alpha_wmb() actually performs a 'mb' and not a 'wmb', but I wanted the code to be more correct since at some point in the future alpha_wmb()'s implementation may switch to being a real 'wmb'.