From: Segher Boessenkool <segher@kernel.crashing.org>
To: Paul Mackerras <paulus@samba.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
ppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH]: powerpc: clarify use of twi/isync in io macros
Date: Thu, 21 Sep 2006 17:06:37 +0200 [thread overview]
Message-ID: <CE7D62D7-5700-488F-91F0-5F732B242EC0@kernel.crashing.org> (raw)
In-Reply-To: <17682.34922.240565.233215@cargo.ozlabs.ibm.com>
>> + * A data-dependent branch followed by an isync ensures that no
>> + * instructions after the isync in program order will be
>> + * (speculatively) executed, so the load that the twi depends
>> + * on has to complete before anything else is executed; in
>
> While the statement about branches is true, it's not especially
> relevant when it comes to twi.
twi is a data-dependent branch -- all exceptions are branches (well
they do change the execution flow!), and this one is generated
directly by an insn even. Traps and "normal" branches are neighbours
in the opcode maps, too, FWIW ;-)
> What's happening is that isync has to
> prevent any following instructions from starting execution until all
> previous instructions have completed, meaning that they have got to
> the point of knowing whether they will generate an exception or not.
It also has to know whether the isync will be executed at all, in
the sequential model.
> In general the processor doesn't know whether twi will generate an
> exception until the data it depends on is available, and that's why
> the isync has to wait for the previous load to have returned the
> data.
Yeah, the main point is that the load insn can complete _before_
the data has come back ("the storage access has been performed"),
so an isync without another insn depending on the load result
won't do.
Care to write some better explanatory text than the rubbish I
came up with? :-)
Btw, you say "in general the CPU doesn't know", but it _can_ know
in this code, as the TO field is 0 (so it can never trap). Is
there anything preventing/forbidding a CPU from optimising this
case? I see it spelled out for "conditional branch" insns, but
it would be interesting to know if the arch guarantees no insn
will complete before its input regs are ready.
prev parent reply other threads:[~2006-09-21 15:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-19 19:30 [PATCH]: powerpc: clarify use of twi/isync in io macros Linas Vepstas
2006-09-19 19:57 ` Segher Boessenkool
2006-09-19 20:10 ` Linas Vepstas
2006-09-19 20:30 ` Segher Boessenkool
2006-09-21 12:41 ` Paul Mackerras
2006-09-21 15:06 ` Segher Boessenkool [this message]
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=CE7D62D7-5700-488F-91F0-5F732B242EC0@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=sfr@canb.auug.org.au \
/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