svn commit: r219679 - head/sys/i386/include

[Jung-uk Kim]

On Thursday 17 March 2011 03:57 pm, Peter Jeremy wrote:
> On 2011-Mar-16 16:34:04 -0400, Jung-uk Kim <jkim at FreeBSD.org> wrote:
> >On Wednesday 16 March 2011 01:45 pm, Roman Divacky wrote:
> >> if we drop i486 I think it makes sense to require something that
> >> has at least SSE2, thus we can have the same expectations as on
> >> amd64.
>
> I think it's stil a bit early for that - especially the SSE2
> requirement.
>
> >This is a proof-of-concept patch for sys/x86/isa/clock.c:
> >
> >http://people.freebsd.org/~jkim/clock.diff
> >
> >You see the complexity, just because I wanted to load 64-bit value
> >atomically... :-(
>
> An alternative approach is to have _fetch_frequency() be
>   uint64_t (*_fetch_frequency)(uint64_t *);
> if i386 and I486 are defined (otherwise it's just the #define
> (*(p))) then initialise it to either atomic_fetch_quad_i386 or
> atomic_fetch_quad_i586 as part of the CPU detection process.  This
> is the way bcopy() is/was handled on Pentium.
>
> Another approach would be to always have cmpxchg8b instructions
> (followed by a suitably large NOP) always inlined in the code and
> if it traps, patch the code to call a function that emulates it.

I think the former makes more sense for atomic read/write because we 
don't need complete cmpxchg8b support but kind of movq support, 
actually.

Thanks for the suggestion.

Jung-uk Kim