On Thursday 17 March 2011 03:57 pm, Peter Jeremy wrote: > On 2011-Mar-16 16:34:04 -0400, Jung-uk Kim <j...@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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"