Date: Thu, 17 Mar 2011 12:23:47 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, Roman Divacky <rdivacky@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, Maxim Dounin <mdounin@mdounin.ru> Subject: Re: svn commit: r219679 - head/sys/i386/include Message-ID: <201103171223.52315.jkim@FreeBSD.org> In-Reply-To: <20110317213445.U1128@besplex.bde.org> References: <201103152145.p2FLjAlt060256@svn.freebsd.org> <201103161634.08104.jkim@FreeBSD.org> <20110317213445.U1128@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 17 March 2011 08:42 am, Bruce Evans wrote: > On Wed, 16 Mar 2011, Jung-uk Kim wrote: > > On Wednesday 16 March 2011 01:45 pm, Roman Divacky wrote: > >> On Wed, Mar 16, 2011 at 12:32:56PM -0400, Jung-uk Kim wrote: > >>> On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: > >>>> This isn't really different as long as GENERIC kernel used, as > >>>> GENERIC defines I486_CPU. > >>> > >>> Fixed in r219698, sorry. > >>> > >>> Actually, I think we should remove i486 from GENERIC at some > >>> point. It has too many limitations. For example, I really love > >>> to implement atomic 64-bit mem read/write using cmpxchg8b (no > >>> 0xf00f joke, please) but I cannot do that cleanly without > >>> removing I486 support or checking cpu_class at run-time. :-( > > I'm not sure how f00f applies to cmpxchg8b, but we still maintain > the f00f workaround (perhaps not well enough to keep it actually > working) though there might be more i486's still running FreeBSD > than there are i586's with the f00f bug, since i486's might be > reimplemented into embedded systems but i586's with the f00f bug > might have been replaced and reimplementations of i586's wouldn't > implement the f00f bug. http://en.wikipedia.org/wiki/Pentium_F00F_bug It was a bug in cmpxchg8b implementation. When I think of cmpxchg8b, 0xf00f just pops up in my mind. I guess I won't forget the (illegal) opcode forever. :-( > >> 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. > >> > >> and we can use sse2 unconditionally (str*, mem* etc.) > > > > This is a proof-of-concept patch for sys/x86/isa/clock.c: > > > > http://people.freebsd.org/~jkim/clock.diff > > Please include patches in mail. It is hard to refer to lines in > urls. (Bunch of comment was here.) I didn't want it to be reviewed. At least, I have no intention to commit it without properlly moving the asm to atomic.h. I just mentioned it to show you the complexity of atomic 64-bit mem read/write *with* i486 support. That's all. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103171223.52315.jkim>