> > The only reason this doesn't have any visible effect is:
> > (1) x86 doesn't have split icache/dcache so no incoherency issues
> >
>
> I think intel new architecture does split instruction cache/data cache.
> http://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.svg
>
> But I
On 27 January 2012 02:55, Xin Tong wrote:
> I think intel new architecture does split instruction cache/data cache.
> http://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.svg
It may have a separate I/D cache in the implementation, but from
the programmer's point of view they are
On Thu, Jan 26, 2012 at 3:55 PM, Peter Maydell wrote:
> On 26 January 2012 19:52, Xin Tong wrote:
> > It seems to me that when QEMU emits a TB to TB transition, it does not
> look
> > for whether the code has already been generated or not ( at least x86 on
> x86
> > emulation) . it just lay down
On 26 January 2012 19:52, Xin Tong wrote:
> It seems to me that when QEMU emits a TB to TB transition, it does not look
> for whether the code has already been generated or not ( at least x86 on x86
> emulation) . it just lay down a 4 byte address, waiting to be patched later.
> Am I right ?
Yes,
It seems to me that when QEMU emits a TB to TB transition, it does not look
for whether the code has already been generated or not ( at least x86 on
x86 emulation) . it just lay down a 4 byte address, waiting to be patched
later. Am I right ?
case INDEX_op_goto_tb:
if (s->tb_jmp_offset)