Add PAUSE hint #398
Add PAUSE hint #398
Conversation
There was a problem hiding this comment.
Right now we use div X, X, x0 as the stand-in for pause in Linux, and that's probably propagated elsewhere. I think this is a better bet: it doesn't require M and it's actually a NOP. I don't think it's even worth commenting in the ISA manual, though, as it'll just cause confusion.
I think we've had this argument before, but I'd prefer to indicate this as a fence with both an I/O bit set and an R/W bit set. This allows us to later disambiguate I/O pauses from memory pauses. I think I have a coherent argument here, LMK if you want to talk about it -- I'm not sure it's worth the time :)
|
I’m probably just rehashing the discussion we already had, but: I don’t think there’s much benefit from distinguishing the two, as the processor can just unstall when either event (IO or memory) occurs, and there’s likely no loss in efficiency in practice. In fact, given the likelihood of misuse, it might perform better this way around ;) I would view the predecessor field as just another opcode field when the successor field is zero. It doesn’t really matter if the bits line up with their usual purpose, as they are feeding into different control logic (or so I claim without proof). I’m not outright opposed to the change, but I need a stronger argument to change my mind. |
|
Can we just talk in person when I'm back next week? I'm running out of
email writing energy... 😁
…On Tue, Jun 25, 2019, 12:04 PM Andrew Waterman ***@***.***> wrote:
I’m probably just rehashing the discussion we already had, but: I don’t
think there’s much benefit from distinguishing the two, as the processor
can just unstall when either event (IO or memory) occurs, and there’s
likely no loss in efficiency in practice. In fact, given the likelihood of
misuse, it might perform better this way around ;)
I would view the predecessor field as just another opcode field when the
successor field is zero. It doesn’t really matter if the bits line up with
their usual purpose, as they are feeding into different control logic (or
so I claim without proof).
I’m not outright opposed to the change, but I need a stronger argument to
change my mind.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#398?email_source=notifications&email_token=AAKRUXXXJOYTQZ53WKJSYPTP4GKOPA5CNFSM4H3CTFY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYO5XYY#issuecomment-505273315>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKRUXSYPMXJYX4S2WA7OBTP4GKOPANCNFSM4H3CTFYQ>
.
|
|
Sure.
On Mon, Jun 24, 2019 at 9:11 PM Palmer Dabbelt <notifications@github.com>
wrote:
… Can we just talk in person when I'm back next week? I'm running out of
email writing energy... 😁
On Tue, Jun 25, 2019, 12:04 PM Andrew Waterman ***@***.***>
wrote:
> I’m probably just rehashing the discussion we already had, but: I don’t
> think there’s much benefit from distinguishing the two, as the processor
> can just unstall when either event (IO or memory) occurs, and there’s
> likely no loss in efficiency in practice. In fact, given the likelihood
of
> misuse, it might perform better this way around ;)
>
> I would view the predecessor field as just another opcode field when the
> successor field is zero. It doesn’t really matter if the bits line up
with
> their usual purpose, as they are feeding into different control logic (or
> so I claim without proof).
>
> I’m not outright opposed to the change, but I need a stronger argument to
> change my mind.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#398?email_source=notifications&email_token=AAKRUXXXJOYTQZ53WKJSYPTP4GKOPA5CNFSM4H3CTFY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYO5XYY#issuecomment-505273315
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKRUXSYPMXJYX4S2WA7OBTP4GKOPANCNFSM4H3CTFYQ
>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#398?email_source=notifications&email_token=AAH3XQU6R4CGIBVGHWN4DALP4GLFJA5CNFSM4H3CTFY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYO574I#issuecomment-505274353>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAH3XQUHOLLGORKBLVJAA7DP4GLFJANCNFSM4H3CTFYQ>
.
|
Merge whenever riscv/riscv-isa-manual#398 is merged.
|
@gfavor this is rebased and ready for merging whenever we deem appropriate. |
|
Minor suggestion: perhaps the enhancements to the HINT discussion could be separated from the addition of the PAUSE discussion. (I suggest this only because there has been some contention about PAUSE on the mailing lists.) |
|
Perhaps you saw Krste response on google ISA list
https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/0VUZAEl6o0g/m/KCYUUMZTCQAJ.
This revision to HINT is distinct from an enhanced version of PAUSE.
There was also extensive discussion on [RISC-V] [tech] Start of 45-day
public review period for "PAUSE Hint instruction" extension.
The enhancement discussion will most likely always occur.
What the process has demonstrated this time is that clarifications and
cleanups of proposals are incorporated,
even if design enhancements with fundamentally substantial changes are not.
On Wed, Dec 16, 2020, 16:38 Nick Knight, <notifications@github.com <mailto:notifications@github.com>> wrote:
Minor suggestion: perhaps the enhancements to the HINT discussion
could be separated from the addition of the PAUSE discussion. (I
suggest this only because there has been some contention about PAUSE
on the mailing lists.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#398 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFAWIKM2BD4VZOHMCC4UQTLSVESE7ANCNFSM4H3CTFYQ>.
|
|
@knightsifive If the PAUSE discussion drags on, I'll separate these changes into two PRs. I kept them together because redoing these LaTeX tables is time-consuming, and the changes are coupled. |
Closes #43