Skip site navigation (1)Skip section navigation (2)
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>