From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: ARMv8 != arm64
Date: Wed, 1 Nov 2017 15:52:51 -0700 [thread overview]
Message-ID: <20171101225251.GZ3659@linux.vnet.ibm.com> (raw)
In-Reply-To: <2ce74586-5ac7-db14-f4e0-2aad297d8481@gmail.com>
On Thu, Nov 02, 2017 at 07:34:28AM +0900, Akira Yokosawa wrote:
> Hi Paul,
>
> In Section 15.4.3, you are treating ARMv8 as 64-bit CPU.
> However, ARMv8 has 32-bit modes A32 and T32.
> Instructions for load-acquire/store-release are also available in A32
> and T32 modes of ARMv8.
>
> The opening paragraph of Section 15.4.3 needs some rework, I guess.
Ah, thank you! How about the following?
Thanx, Paul
------------------------------------------------------------------------
commit 1a41fa1352ff77c3a09a4d182649e571735d7f1c
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Wed Nov 1 15:51:06 2017 -0700
memorder: ARMv8 includes 32-bit capability
Reported-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/memorder/memorder.tex b/memorder/memorder.tex
index 94e125ab3412..446f4804af53 100644
--- a/memorder/memorder.tex
+++ b/memorder/memorder.tex
@@ -4485,10 +4485,11 @@ lines~3 and~4 would enforce ordering between lines~1 and~5.
\ContributedBy{Figure}{fig:memorder:Half Memory Barrier}{Melissa Brossard}
\end{figure}
-ARMv8 is ARM's 64-bit CPU~\cite{ARMv8A:2017},
-in contrast to their 32-bit CPU described in
+ARMv8 is ARM's new CPU family~\cite{ARMv8A:2017}
+which includes 64-bit capabilities,
+in contrast to their 32-bit-only CPU described in
Section~\ref{sec:memorder:ARMv7-A/R}.
-ARMv8's memory model closely resembles its 32-bit counterpart,
+ARMv8's memory model closely resembles its ARMv7 counterpart,
but adds load-acquire (\co{LDLARB}, \co{LDLARH}, and \co{LDLAR})
and store-release (\co{STLLRB}, \co{STLLRH}, and \co{STLLR})
instructions.
@@ -4569,7 +4570,7 @@ being weakly ordered by default, but respecting dependencies.
MIPS has a wide variety of memory-barrier instructions, but ties them
not to hardware considerations, but rather to the use cases provided
by the Linux kernel and the C++11 standard~\cite{RichardSmith2015N4527}
-in a manner similar to the ARM64 additions:
+in a manner similar to the ARMv8 additions:
\begin{description}[style=nextline]
\item[\tco{SYNC}]
next prev parent reply other threads:[~2017-11-01 22:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 22:34 ARMv8 != arm64 Akira Yokosawa
2017-11-01 22:52 ` Paul E. McKenney [this message]
2017-11-01 23:22 ` Akira Yokosawa
2017-11-02 2:52 ` Paul E. McKenney
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=20171101225251.GZ3659@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akiyks@gmail.com \
--cc=perfbook@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox