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.
next prev parent 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.