lkml.org 
[lkml]   [2003]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this
Russell King wrote:
> > > If you take a moment to think about what should be going on -
> > >
> > > - first write gets translated to physical address, and the address with
> > > the data is placed in the write buffer.
> > > - second write gets translated to the same physical address, and the
> > > address and data is placed into the write buffer such that we store
> > > the first write then the second write to the same physical memory.
> > > - reading from the first mapping should return the second writes value
> > > no matter what.
> >
> > That is an incomplete explanation, because it should never be possible
> > for reads to access data from the write buffer which isn't the most
> > recent.
>
> Umm, that's what I said.

You say that "reading from the first mapping _should_ return the
second write value no matter what", but that there's a bug in the
write buffer and it isn't doing that.

I'm saying that the bug can't be that, because such a bug would affect
normal applications.

> > Don't some of the ARMs executed two instructions concurrently, like
> > the original Pentium?
>
> Nope - they're all single issue CPUs, and, if non-buggy, they guarantee
> that stores never bypass loads. (In a later architecture revision, this
> is controllable.)
>
> Remember - ARM CPUs aren't a high spec desktop CPU. They're an embedded
> CPU where power consumption matters. Superscalar/multiple issue/high
> performance isn't viable in such many embedded environments.

Fair enough. I recall someone mentioning a dual issue ARM once upon a
time, that's all.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Russell King wrote:
> > > If you take a moment to think about what should be going on -
> > >
> > > - first write gets translated to physical address, and the address with
> > > the data is placed in the write buffer.
> > > - second write gets translated to the same physical address, and the
> > > address and data is placed into the write buffer such that we store
> > > the first write then the second write to the same physical memory.
> > > - reading from the first mapping should return the second writes value
> > > no matter what.
> >
> > That is an incomplete explanation, because it should never be possible
> > for reads to access data from the write buffer which isn't the most
> > recent.
>
> Umm, that's what I said.

You say that "reading from the first mapping _should_ return the
second write value no matter what", but that there's a bug in the
write buffer and it isn't doing that.

I'm saying that the bug can't be that, because such a bug would affect
normal applications.

> > Don't some of the ARMs executed two instructions concurrently, like
> > the original Pentium?
>
> Nope - they're all single issue CPUs, and, if non-buggy, they guarantee
> that stores never bypass loads. (In a later architecture revision, this
> is controllable.)
>
> Remember - ARM CPUs aren't a high spec desktop CPU. They're an embedded
> CPU where power consumption matters. Superscalar/multiple issue/high
> performance isn't viable in such many embedded environments.

Fair enough. I recall someone mentioning a dual issue ARM once upon a
time, that's all.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.220 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site