From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 31 11:33:32 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15A8E16A419; Mon, 31 Dec 2007 11:33:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id B217613C448; Mon, 31 Dec 2007 11:33:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J9Itc-0001Yi-4N; Mon, 31 Dec 2007 13:33:30 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBVBXRKa061172; Mon, 31 Dec 2007 13:33:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBVBXRgH061171; Mon, 31 Dec 2007 13:33:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 31 Dec 2007 13:33:27 +0200 From: Kostik Belousov To: Erich Dollansky Message-ID: <20071231113327.GN57756@deviant.kiev.zoral.com.ua> References: <47760132.5040306@pacific.net.sg> <20071229111204.GX57756@deviant.kiev.zoral.com.ua> <20071230131056.GG57756@deviant.kiev.zoral.com.ua> <4778B8A3.8040400@pacific.net.sg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rkfdwoJB1s8W8pdr" Content-Disposition: inline In-Reply-To: <4778B8A3.8040400@pacific.net.sg> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 8d26fb09d298f8c1cb325fc86345eca8 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1976 [Dec 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: Kip Macy , Ivan Voras , freebsd-hackers@freebsd.org Subject: Re: Architectures with strict alignment? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2007 11:33:32 -0000 --rkfdwoJB1s8W8pdr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 31, 2007 at 05:38:43PM +0800, Erich Dollansky wrote: > Hi, >=20 > Kostik Belousov wrote: > >On Sat, Dec 29, 2007 at 01:12:04PM +0200, Kostik Belousov wrote: > >>On Sat, Dec 29, 2007 at 12:14:11AM -0800, Kip Macy wrote: > > > >I.e., it seems that gcc does not feel too guilty generating unaligned > >half-word writes on i386. :( >=20 > this should not be a problem inside a cache line. >=20 > If the access goes accross two cache lines and the other cache line is=20 > not in the cache, it becomes real difficult. >=20 > I can't tell you what the hardware actually does in this case. >=20 > It should read the second affected cache line into the cache. But what=20 > happens if the second affected cache line is blocked by another CPU=20 > while the current CPU blocks the first cache line? =46rom the manual, 253668, 7.1.1: Accesses to cacheable memory that are split across bus widths, cache lines, and page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors. The Intel Core 2 Duo, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, and P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided. I think we might get any half of the operation as a result. --rkfdwoJB1s8W8pdr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHeNOGC3+MBN1Mb4gRAufQAKClWTHINgpi/1zY2srN/SAMrdTnJQCgtnzh P9T/Ljo3zDfDVRzZ8wnTFoM= =jND5 -----END PGP SIGNATURE----- --rkfdwoJB1s8W8pdr--