Date: Mon, 31 Dec 2007 20:30:35 +0800 From: Erich Dollansky <oceanare@pacific.net.sg> To: Kostik Belousov <kostikbel@gmail.com> Cc: Kip Macy <kip.macy@gmail.com>, Ivan Voras <ivoras@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: Architectures with strict alignment? Message-ID: <4778E0EB.8040709@pacific.net.sg> In-Reply-To: <20071231113327.GN57756@deviant.kiev.zoral.com.ua> References: <fl4c8o$vpu$1@ger.gmane.org> <47760132.5040306@pacific.net.sg> <b1fa29170712290014w780448bh8da93006a629b7b4@mail.gmail.com> <20071229111204.GX57756@deviant.kiev.zoral.com.ua> <20071230131056.GG57756@deviant.kiev.zoral.com.ua> <4778B8A3.8040400@pacific.net.sg> <20071231113327.GN57756@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Kostik Belousov wrote: > On Mon, Dec 31, 2007 at 05:38:43PM +0800, Erich Dollansky wrote: >> 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. :( >> this should not be a problem inside a cache line. >> >> If the access goes accross two cache lines and the other cache line is >> not in the cache, it becomes real difficult. >> >> I can't tell you what the hardware actually does in this case. >> >> It should read the second affected cache line into the cache. But what >> happens if the second affected cache line is blocked by another CPU >> while the current CPU blocks the first cache line? > > From the manual, 253668, 7.1.1: > > I think we might get any half of the operation as a result. so, both CPUs are blocked as none can access the other cache line. Is there really nothing in a normal PC to handle this? I do not know. The hardware I developed earlier was able to handle this by aborting both bus cycles. It was then task of the operating system to handle this. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4778E0EB.8040709>