All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kim, Jong-Sung" <jsungkim@lge.com>
To: "'Kevin D. Kissell'" <kevink@mips.com>
Cc: <linux-mips@linux-mips.org>
Subject: RE: Reading an entire cacheline
Date: Thu, 27 Apr 2006 14:04:07 +0900	[thread overview]
Message-ID: <00fc01c669b8$0319f6d0$f3479696@LGE.NET> (raw)
In-Reply-To: <005701c66924$00a74860$10eca8c0@grendel>

Dear Mr. Kissell,

Thank you for your advices about disassembling. Please see:

1380:	...
1384:	00431025	or	v0,v0,v1
1388:	00441025	or	v0,v0,a0
138c:	bc450000	cache	0x5,0(v0)
1390:	4002e000	mfc0	v0,c0_taglo
1394:	4003e001	mfc0	v1,c0_datalo
1398:	4004e801	mfc0	a0,c0_datahi
139c:	bc450008	cache	0x5,8(v0)
13a0:	4005e000	mfc0	a1,c0_taglo
13a4:	4006e001	mfc0	a2,c0_datalo
13a8:	4007e801	mfc0	a3,c0_datahi
13ac:	bc450010	cache	0x5,16(v0)
13b0:	4008e000	mfc0	t0,c0_taglo
13b4:	4009e001	mfc0	t1,c0_datalo
13b8:	400ae801	mfc0	t2,c0_datahi
13bc:	bc450010	cache	0x5,16(v0)
13c0:	400be000	mfc0	t3,c0_taglo
13c4:	400ee001	mfc0	t6,c0_datalo
13c8:	400ce801	mfc0	t4,c0_datahi
13cc:	ae020020	sw	v0,32(s0)
13d0:	ae030060	sw	v1,96(s0)
13d4:	...

It seems no memory variable is accessed during the sequence. The obviously
unexpected thing is the use of register v0. It should have the value of the
index and should not be touched before the execution of the last cache
instruction. In this way, tags read are doomed to be different.

It's my fault. So, I corrected the "=r" to be "=&r", and it seems work.
Thank you again.

Regards,
JS.


-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Kevin D. Kissell
Sent: Wednesday, April 26, 2006 8:25 PM
To: Kim, Jong-Sung; Thiemo Seufer
Cc: linux-mips@linux-mips.org
Subject: Re: Reading an entire cacheline

> [snip]
> > //" bne %0, %9, 2b\n"
> > " .set mips0\n"
> > " .set reorder"
> > : "=r" (tag[1][way][0]), "=r" (datalo[1][way][0]),
> >   "=r" (datahi[1][way][0]),
> >   "=r" (tag[1][way][1]), "=r" (datalo[1][way][1]),
> >   "=r" (datahi[1][way][1]),
> >   "=r" (tag[1][way][2]), "=r" (datalo[1][way][2]),
> >   "=r" (datahi[1][way][2]),
> >   "=r" (tag[1][way][3]), "=r" (datalo[1][way][3]),
> >   "=r" (datahi[1][way][3])
> > : "r" (0x80000000 | (way << 14) | (line << 5))
> > );
> 
> And this part may cause the problem you are seeing, I presume
> datalo/datahi live in memory, and accesses of it change the dcache.

As I was hoping disassembly would demonstrate for you,
declaring "=r" doesn't mean that the variable has no life
outside a register.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kim, Jong-Sung" <jsungkim@lge.com>
To: "'Kevin D. Kissell'" <kevink@mips.com>
Cc: linux-mips@linux-mips.org
Subject: RE: Reading an entire cacheline
Date: Thu, 27 Apr 2006 14:04:07 +0900	[thread overview]
Message-ID: <00fc01c669b8$0319f6d0$f3479696@LGE.NET> (raw)
Message-ID: <20060427050407.gZw3uA_ji-5iXtoppKrLxpsJnaMvfCvzsrKBuizTudY@z> (raw)
In-Reply-To: <005701c66924$00a74860$10eca8c0@grendel>

Dear Mr. Kissell,

Thank you for your advices about disassembling. Please see:

1380:	...
1384:	00431025	or	v0,v0,v1
1388:	00441025	or	v0,v0,a0
138c:	bc450000	cache	0x5,0(v0)
1390:	4002e000	mfc0	v0,c0_taglo
1394:	4003e001	mfc0	v1,c0_datalo
1398:	4004e801	mfc0	a0,c0_datahi
139c:	bc450008	cache	0x5,8(v0)
13a0:	4005e000	mfc0	a1,c0_taglo
13a4:	4006e001	mfc0	a2,c0_datalo
13a8:	4007e801	mfc0	a3,c0_datahi
13ac:	bc450010	cache	0x5,16(v0)
13b0:	4008e000	mfc0	t0,c0_taglo
13b4:	4009e001	mfc0	t1,c0_datalo
13b8:	400ae801	mfc0	t2,c0_datahi
13bc:	bc450010	cache	0x5,16(v0)
13c0:	400be000	mfc0	t3,c0_taglo
13c4:	400ee001	mfc0	t6,c0_datalo
13c8:	400ce801	mfc0	t4,c0_datahi
13cc:	ae020020	sw	v0,32(s0)
13d0:	ae030060	sw	v1,96(s0)
13d4:	...

It seems no memory variable is accessed during the sequence. The obviously
unexpected thing is the use of register v0. It should have the value of the
index and should not be touched before the execution of the last cache
instruction. In this way, tags read are doomed to be different.

It's my fault. So, I corrected the "=r" to be "=&r", and it seems work.
Thank you again.

Regards,
JS.


-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Kevin D. Kissell
Sent: Wednesday, April 26, 2006 8:25 PM
To: Kim, Jong-Sung; Thiemo Seufer
Cc: linux-mips@linux-mips.org
Subject: Re: Reading an entire cacheline

> [snip]
> > //" bne %0, %9, 2b\n"
> > " .set mips0\n"
> > " .set reorder"
> > : "=r" (tag[1][way][0]), "=r" (datalo[1][way][0]),
> >   "=r" (datahi[1][way][0]),
> >   "=r" (tag[1][way][1]), "=r" (datalo[1][way][1]),
> >   "=r" (datahi[1][way][1]),
> >   "=r" (tag[1][way][2]), "=r" (datalo[1][way][2]),
> >   "=r" (datahi[1][way][2]),
> >   "=r" (tag[1][way][3]), "=r" (datalo[1][way][3]),
> >   "=r" (datahi[1][way][3])
> > : "r" (0x80000000 | (way << 14) | (line << 5))
> > );
> 
> And this part may cause the problem you are seeing, I presume
> datalo/datahi live in memory, and accesses of it change the dcache.

As I was hoping disassembly would demonstrate for you,
declaring "=r" doesn't mean that the variable has no life
outside a register.

            Regards,

            Kevin K.

  reply	other threads:[~2006-04-27  5:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-24  9:52 Reading an entire cacheline Kim, Jong-Sung
2006-04-24  9:52 ` Kim, Jong-Sung
2006-04-26  8:47 ` Kim, Jong-Sung
2006-04-26  8:47   ` Kim, Jong-Sung
2006-04-26  9:48   ` Kevin D. Kissell
2006-04-26  9:48     ` Kevin D. Kissell
2006-04-26 10:16   ` Thiemo Seufer
2006-04-26 11:24     ` Kevin D. Kissell
2006-04-26 11:24       ` Kevin D. Kissell
2006-04-27  5:04       ` Kim, Jong-Sung [this message]
2006-04-27  5:04         ` Kim, Jong-Sung
2006-04-27  5:13     ` Kim, Jong-Sung
2006-04-27  5:13       ` Kim, Jong-Sung
  -- strict thread matches above, loose matches on Subject: below --
2006-04-18  0:37 Kim, Jong-Sung
2006-04-18  0:37 ` Kim, Jong-Sung
2006-04-24  7:23 ` Kim, Jong-Sung
2006-04-24  7:23   ` Kim, Jong-Sung
2006-04-24  7:40   ` Kevin D. Kissell
2006-04-24  7:40     ` Kevin D. Kissell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00fc01c669b8$0319f6d0$f3479696@LGE.NET' \
    --to=jsungkim@lge.com \
    --cc=kevink@mips.com \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.