C.MV implementation detail leaking into spec?
77 views
Skip to first unread message
Luke Kenneth Casson Leighton
Jun 11, 2018, 10:32:13 PM6/11/18
to RISC-V ISA Dev
page 90 of the current V2.3-Draft, section on integer
register-register operations says:
C.MV copies the value in register rs2 into register rd. C.MV expands
into add rd, x0, rs2.
C.MV expands to a different instruction than the canonical MV
pseudoinstruction, which instead
uses ADDI. Implementations that handle MV specially, e.g. using
register-renaming hardware,
may find it more convenient to expand C.MV to MV instead of ADD,
at slight additional hard-
ware cost.
so the italics paragraph makes it clear that the expansion is an
implementation *recommendation*.... however (and i have had at least
one conversation with someone already who was distinctly under this
impression) the wording "C.MV expands into add rd, x0, rs2" can - and
has been - intepreted that it is an ABSOLUTE HARD REQUIREMENT to
expand and implement C.MV as "add rd, x0, rs2" and NOTHING ELSE is
permitted.
if the words were changed e.g. to "it is recommended that C.MV be
expanded into add rd, x0, rs2" then this would be clearer... if that
is the intention.
so the question is: is it the specific intention to restrict and limit
implementations to *only* be able to implement C.MV as add rd x0 rs2?
also, later in the italics paragraph, MV is mentioned... but there's
no actual MV instruction: MV is a pseudo-op. so... how could C.MV - a
*real* instruction - be expanded to a *pseudo-op* instruction? was it
at one point an actual instruction (in an earlier draft), such that
this is now an oversight?
the comparison of C.MV to MV here has also been the source of some
confusion, as it is implied, through equality (the words "to expand
C.MV to MV") that C.MV must also be a pseudo-op, when it isn't.
l.
register-register operations says:
C.MV copies the value in register rs2 into register rd. C.MV expands
into add rd, x0, rs2.
C.MV expands to a different instruction than the canonical MV
pseudoinstruction, which instead
uses ADDI. Implementations that handle MV specially, e.g. using
register-renaming hardware,
may find it more convenient to expand C.MV to MV instead of ADD,
at slight additional hard-
ware cost.
so the italics paragraph makes it clear that the expansion is an
implementation *recommendation*.... however (and i have had at least
one conversation with someone already who was distinctly under this
impression) the wording "C.MV expands into add rd, x0, rs2" can - and
has been - intepreted that it is an ABSOLUTE HARD REQUIREMENT to
expand and implement C.MV as "add rd, x0, rs2" and NOTHING ELSE is
permitted.
if the words were changed e.g. to "it is recommended that C.MV be
expanded into add rd, x0, rs2" then this would be clearer... if that
is the intention.
so the question is: is it the specific intention to restrict and limit
implementations to *only* be able to implement C.MV as add rd x0 rs2?
also, later in the italics paragraph, MV is mentioned... but there's
no actual MV instruction: MV is a pseudo-op. so... how could C.MV - a
*real* instruction - be expanded to a *pseudo-op* instruction? was it
at one point an actual instruction (in an earlier draft), such that
this is now an oversight?
the comparison of C.MV to MV here has also been the source of some
confusion, as it is implied, through equality (the words "to expand
C.MV to MV") that C.MV must also be a pseudo-op, when it isn't.
l.
Andrew Waterman
Jun 11, 2018, 10:44:20 PM6/11/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
On Mon, Jun 11, 2018 at 7:32 PM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
page 90 of the current V2.3-Draft, section on integer
register-register operations says:
C.MV copies the value in register rs2 into register rd. C.MV expands
into add rd, x0, rs2.
C.MV expands to a different instruction than the canonical MV
pseudoinstruction, which instead
uses ADDI. Implementations that handle MV specially, e.g. using
register-renaming hardware,
may find it more convenient to expand C.MV to MV instead of ADD,
at slight additional hard-
ware cost.
so the italics paragraph makes it clear that the expansion is an
implementation *recommendation*.... however (and i have had at least
one conversation with someone already who was distinctly under this
impression) the wording "C.MV expands into add rd, x0, rs2" can - and
has been - intepreted that it is an ABSOLUTE HARD REQUIREMENT to
expand and implement C.MV as "add rd, x0, rs2" and NOTHING ELSE is
permitted.
That doesn’t make sense, since the expansion from RVC to RVI isn’t architecturally exposed. (Some microarchitectures might not even explicitly expand RVC instructions.)
if the words were changed e.g. to "it is recommended that C.MV be
expanded into add rd, x0, rs2" then this would be clearer... if that
is the intention.
so the question is: is it the specific intention to restrict and limit
implementations to *only* be able to implement C.MV as add rd x0 rs2?
also, later in the italics paragraph, MV is mentioned... but there's
no actual MV instruction: MV is a pseudo-op. so... how could C.MV - a
*real* instruction - be expanded to a *pseudo-op* instruction? was it
at one point an actual instruction (in an earlier draft), such that
this is now an oversight?
the comparison of C.MV to MV here has also been the source of some
confusion, as it is implied, through equality (the words "to expand
C.MV to MV") that C.MV must also be a pseudo-op, when it isn't.
l.
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPweEDyDFmJUktwJh4%2Bg9e_af4A_iP2uH%2B%3DmWDU4gxK96v1s%3Dg%40mail.gmail.com.
Luke Kenneth Casson Leighton
Jun 11, 2018, 11:02:49 PM6/11/18
to Andrew Waterman, RISC-V ISA Dev
"C.MV expands into add rd, x0, rs2".
the meaning of those words is quite clear: implementors *must* expand
and implement C.MV as add rd, x0, rs2 - they are not given any choice
in the matter, no matter whether it does or does not make sense....
because that's what the specification explicity states (or demands).
it's a specification: the penalty for failing to comply with the
specification is that you do not get endorsement through the RISC-V
Foundation, and that means you can't sell branded product.
i've had one conversation already last week with someone who, when i
said that i intended to implement C.MV differently from "add rd, x0,
rs2" i was told quite unequivocably that doing so was *not* permitted
by the specification.
now, it's only the italics that paragraph that contradict that... and
suddenly the situation is no longer clear. the *intent* is
understood... retrospectively, but a specification cannot be written
based on intent: the wording has to be taken as absolute, literal and
nailed-to-the-floor.
so, which is it? is it that C.MV is permitted to be implemented any
way that implementors choose? or is it the case that C.MV *must* be
implemented - no choice in the matter - as "add rd, x0, rs2"?
l.
Andrew Waterman
Jun 11, 2018, 11:19:10 PM6/11/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
Yes, it would have been more precise to say that C.MV must *appear to* expand to ADD.
As a general statement, any implementation technique that results in indistinguishable architectural state changes is legal. This is the concept of microarchitecture. It doesn’t make sense to express this sentiment in the C-extension chapter, because it applies to any implementation of any ISA.
Luke Kenneth Casson Leighton
Jun 11, 2018, 11:30:09 PM6/11/18
to Andrew Waterman, RISC-V ISA Dev
On Tue, Jun 12, 2018 at 4:18 AM, Andrew Waterman
my understanding is that IETF RFC language recommends the use of the
word "may" for these circumstances.
> As a general statement, any implementation technique that results in
> indistinguishable architectural state changes is legal.
indeed. however in this particular case it's quite clear that
implementors *must* implement (expand) C.MV as (to) "add rd x0 rs2",
and readers may simply stop at that sentence, not reading any further
as they may be under the impression that the italics are for
"guidance" or "not relevant", particularly if english is not their
first language.
> This is the concept
> of microarchitecture. It doesn’t make sense to express this sentiment in the
> C-extension chapter, because it applies to any implementation of any ISA.
agreed, it's an implicit understanding covering the whole document...
unfortunately in this particular instance the wording over-rides that
understanding through the implication that C.MV *must* be implemented
as "add rd x0 rs2", notwithstanding the subsequent paragraph that
contradicts that.
it does need to be clarified, is what i'm saying. the word "may" can
be inserted "C.MV may be expanded to ..." however i think even better
would be for that sentence to then be moved into the italicised
paragraph.
throughout the spec the italicised paragraphs are consistently seen
to be a conversational "clarification" or "additional background
informational" that doesn't actually get read as "actual hard
requirements".
l.
word "may" for these circumstances.
> As a general statement, any implementation technique that results in
> indistinguishable architectural state changes is legal.
implementors *must* implement (expand) C.MV as (to) "add rd x0 rs2",
and readers may simply stop at that sentence, not reading any further
as they may be under the impression that the italics are for
"guidance" or "not relevant", particularly if english is not their
first language.
> This is the concept
> of microarchitecture. It doesn’t make sense to express this sentiment in the
> C-extension chapter, because it applies to any implementation of any ISA.
unfortunately in this particular instance the wording over-rides that
understanding through the implication that C.MV *must* be implemented
as "add rd x0 rs2", notwithstanding the subsequent paragraph that
contradicts that.
it does need to be clarified, is what i'm saying. the word "may" can
be inserted "C.MV may be expanded to ..." however i think even better
would be for that sentence to then be moved into the italicised
paragraph.
throughout the spec the italicised paragraphs are consistently seen
to be a conversational "clarification" or "additional background
informational" that doesn't actually get read as "actual hard
requirements".
l.
Andrew Waterman
Jun 11, 2018, 11:51:39 PM6/11/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
I’m amenable to clarifying the text, but I think this mangles the meaning in a different way. “Must appear to expand to” makes it clear that the semantics must be equivalent to the corresponding base instruction. “May expand to” is weaker.
I’ll propose an alternative modification that gives a caveat at the front of the RVC chapter, rather than altering the rest of the text.
Luke Kenneth Casson Leighton
Jun 12, 2018, 12:14:01 AM6/12/18
to Andrew Waterman, RISC-V ISA Dev
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jun 12, 2018 at 4:51 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
> I’m amenable to clarifying the text, but I think this mangles the meaning in
> a different way. “Must appear to expand to” makes it clear that the
> semantics must be equivalent to the corresponding base instruction. “May
> expand to” is weaker.
good point. ohh i know what was intended: it was intended to be said
that the C.MV appears to be equivalent to... yes, i get you now. ok
so how about this - again, in the Commentary:
+Implementations may expand C.MV so that it appears to be
+functionally equivalent to {\tt add rd, x0, rs2}.
(1) the sentence about what C.MV is - which is quite short - is
perfectly clear and has (and needs) no... commentary, or
implementation guidance, or advice. i.e. the sentence "C.MV copies
the value in register {\em rs2} into register {\em rd}." is really
clear.
(2) the commentary is now clear that it is about implementation
advice, and nothing else. it specifically starts with the words
"implementations may...", which tells readers definitively, "this
paragraph is definitely NOT about specification details, it's about
*implementation* details / advice".
(3) by using the phrase "appears to be functionally equivalent to"
it's clear that the intent is that implementors must make C.MV be *as
if* add rd x0 rs2 had been carried out, i.e. it's a little bit of
extra clarification but also it gives the hint that implementors may
actually choose to implement C.MV precisely *as* "add rd x0 rs2"...
without actually telling them (forcing them) to do precisely that.
the bits about C.MV being a real instruction whilst MV doesn't exist
and is a pseudoinstruction... yyeah it's confusing but nowhere near as
critical.
l.
> I’ll propose an alternative modification that gives a caveat at the front of
> the RVC chapter, rather than altering the rest of the text.
>
> On Mon, Jun 11, 2018 at 8:40 PM Luke Kenneth Casson Leighton <lk...@lkcl.net>
> wrote:
>>
>> attached diff: moves the sentence into the commentary block (ha!
>> that's the word i was looking for: "commentary"), adds "may" and
>> changes "expands" to "may be expanded".
>>
>> l.
>
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jun 12, 2018 at 4:51 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
> I’m amenable to clarifying the text, but I think this mangles the meaning in
> a different way. “Must appear to expand to” makes it clear that the
> semantics must be equivalent to the corresponding base instruction. “May
> expand to” is weaker.
that the C.MV appears to be equivalent to... yes, i get you now. ok
so how about this - again, in the Commentary:
+Implementations may expand C.MV so that it appears to be
+functionally equivalent to {\tt add rd, x0, rs2}.
C.MV expands to a different instruction than the canonical MV
pseudoinstruction, which instead uses ADDI. Implementations that handle MV
specially, e.g. using register-renaming hardware, may find it more convenient
that way, the following things are achieved:
pseudoinstruction, which instead uses ADDI. Implementations that handle MV
specially, e.g. using register-renaming hardware, may find it more convenient
(1) the sentence about what C.MV is - which is quite short - is
perfectly clear and has (and needs) no... commentary, or
implementation guidance, or advice. i.e. the sentence "C.MV copies
the value in register {\em rs2} into register {\em rd}." is really
clear.
(2) the commentary is now clear that it is about implementation
advice, and nothing else. it specifically starts with the words
"implementations may...", which tells readers definitively, "this
paragraph is definitely NOT about specification details, it's about
*implementation* details / advice".
(3) by using the phrase "appears to be functionally equivalent to"
it's clear that the intent is that implementors must make C.MV be *as
if* add rd x0 rs2 had been carried out, i.e. it's a little bit of
extra clarification but also it gives the hint that implementors may
actually choose to implement C.MV precisely *as* "add rd x0 rs2"...
without actually telling them (forcing them) to do precisely that.
the bits about C.MV being a real instruction whilst MV doesn't exist
and is a pseudoinstruction... yyeah it's confusing but nowhere near as
critical.
l.
> I’ll propose an alternative modification that gives a caveat at the front of
> the RVC chapter, rather than altering the rest of the text.
>
> On Mon, Jun 11, 2018 at 8:40 PM Luke Kenneth Casson Leighton <lk...@lkcl.net>
> wrote:
>>
>> attached diff: moves the sentence into the commentary block (ha!
>> that's the word i was looking for: "commentary"), adds "may" and
>> changes "expands" to "may be expanded".
>>
>> l.
>
> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0CwHEcQaza7KvG_djnC5Y4FxH1PzYqDS-1YnXWRdRhPTQ%40mail.gmail.com.
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
Andrew Waterman
Jun 12, 2018, 8:30:18 PM6/12/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
Rather than patching the description of C.MV, I'm proposing the
following new text in the chapter's introduction:
Throughout this chapter, we prescribe canonical expansions of RVC instructions
into 32-bit instructions. We briefly note that valid implementations might not
explicitly expand RVC instructions in this manner.
On Mon, Jun 11, 2018 at 9:13 PM, Luke Kenneth Casson Leighton
following new text in the chapter's introduction:
Throughout this chapter, we prescribe canonical expansions of RVC instructions
into 32-bit instructions. We briefly note that valid implementations might not
explicitly expand RVC instructions in this manner.
On Mon, Jun 11, 2018 at 9:13 PM, Luke Kenneth Casson Leighton
Luke Kenneth Casson Leighton
Jun 12, 2018, 8:55:21 PM6/12/18
to Andrew Waterman, RISC-V ISA Dev
On Wed, Jun 13, 2018 at 1:29 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
> Rather than patching the description of C.MV, I'm proposing the
> following new text in the chapter's introduction:
>
> Throughout this chapter, we prescribe canonical expansions of RVC instructions
> into 32-bit instructions. We briefly note that valid implementations might not
> explicitly expand RVC instructions in this manner.
my feeling is that the consequences will be that many people will not
<wate...@eecs.berkeley.edu> wrote:
> Rather than patching the description of C.MV, I'm proposing the
> following new text in the chapter's introduction:
>
> Throughout this chapter, we prescribe canonical expansions of RVC instructions
> into 32-bit instructions. We briefly note that valid implementations might not
> explicitly expand RVC instructions in this manner.
see this (particularly if skimming and searching)... or they will read
it and not realise what it relates to. they will then either make the
mistake of reading the section on C.MV and interpret it that they are
forced to implement C.MV as add r0 x0 rs2 (with no choice but to do
exactly that), and a small percentage will seek clarification again
and again here on the list.
basically not everyone has been working with the manual and the ISA
for years, andrew: they haven't got the details memorised. the
document needs to be designed from the perspective of people who have
little-to-zero knowledge, and who use the document as an extension of
their memory.
i worked for CEDAR audio back in 1993, and reviewed and proof-read
their manuals. they were incredibly tedious: information and
instructions repeated again and again. the users said that they were
the best manuals they'd ever read. why? because they could scan
through it, find the relevant page, and *everything* they needed was
right there, on *that* page. there wasn't a single sentence "for more
information see section X" anywhere in the document.
whilst i would not recommend such an extreme rule (no "see secttion
X") as it makes the document a pig to maintain, i do feel that CEDAR
audio had the right general idea of clarifying at the relevant
section.
i'm overdoing it, basically i'm saying i don't think the proposed
change will be effective.
l.
Andrew Waterman
Jun 12, 2018, 9:03:13 PM6/12/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
On Tue, Jun 12, 2018 at 5:54 PM, Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
> On Wed, Jun 13, 2018 at 1:29 AM, Andrew Waterman
> <wate...@eecs.berkeley.edu> wrote:
>
>> Rather than patching the description of C.MV, I'm proposing the
>> following new text in the chapter's introduction:
>>
>> Throughout this chapter, we prescribe canonical expansions of RVC instructions
>> into 32-bit instructions. We briefly note that valid implementations might not
>> explicitly expand RVC instructions in this manner.
>
> my feeling is that the consequences will be that many people will not
> see this (particularly if skimming and searching)... or they will read
> it and not realise what it relates to. they will then either make the
> mistake of reading the section on C.MV and interpret it that they are
> forced to implement C.MV as add r0 x0 rs2 (with no choice but to do
> exactly that), and a small percentage will seek clarification again
> and again here on the list.
I'm quite unclear on why you think C.MV is the confusing case. The
<lk...@lkcl.net> wrote:
> On Wed, Jun 13, 2018 at 1:29 AM, Andrew Waterman
> <wate...@eecs.berkeley.edu> wrote:
>
>> Rather than patching the description of C.MV, I'm proposing the
>> following new text in the chapter's introduction:
>>
>> Throughout this chapter, we prescribe canonical expansions of RVC instructions
>> into 32-bit instructions. We briefly note that valid implementations might not
>> explicitly expand RVC instructions in this manner.
>
> my feeling is that the consequences will be that many people will not
> see this (particularly if skimming and searching)... or they will read
> it and not realise what it relates to. they will then either make the
> mistake of reading the section on C.MV and interpret it that they are
> forced to implement C.MV as add r0 x0 rs2 (with no choice but to do
> exactly that), and a small percentage will seek clarification again
> and again here on the list.
other RVC instructions are described in the same fashion, e.g., "C.LI
expands into addi rd, x0, imm[5:0]." Like C.MV, there's no reason
C.LI must be implemented with this particular expansion.
If we were to only write a caveat about C.MV, it would make the manual
more confusing, by implying C.MV is special. It's not.
Luke Kenneth Casson Leighton
Jun 12, 2018, 9:14:37 PM6/12/18
to Andrew Waterman, RISC-V ISA Dev
On Wed, Jun 13, 2018 at 2:02 AM, Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
> I'm quite unclear on why you think C.MV is the confusing case. The
> other RVC instructions are described in the same fashion, e.g., "C.LI
> expands into addi rd, x0, imm[5:0]." Like C.MV, there's no reason
> C.LI must be implemented with this particular expansion.
>
> If we were to only write a caveat about C.MV, it would make the manual
> more confusing, by implying C.MV is special. It's not.
ok so you're saying there's more (which i had missed).
<wate...@eecs.berkeley.edu> wrote:
> I'm quite unclear on why you think C.MV is the confusing case. The
> other RVC instructions are described in the same fashion, e.g., "C.LI
> expands into addi rd, x0, imm[5:0]." Like C.MV, there's no reason
> C.LI must be implemented with this particular expansion.
>
> If we were to only write a caveat about C.MV, it would make the manual
> more confusing, by implying C.MV is special. It's not.
so i'm quite happy to review those as well and comprehensively check
the language in each case and get back to you. i *believe* the reason
that i'm picking up on this one is because it's the only one that
makes the mistake of implying that the (REAL) instruction is a
pseudo-one.
yeah. i think that's it. without doing a full analysis (yet) i
think C.MV is the only instruction that i've encountered that is
actually real.
i know about FMV-FABS-FNEG being FSGNJ already (read that again
yesterday, so i know there's no confusing language there). i know
about MV (as i checked that as part of this discussion) and there's no
confusing language there.
ha, i've found table 23.2 - i'll get back to you.
l.
Guy Lemieux
Jun 12, 2018, 9:16:14 PM6/12/18
to Andrew Waterman, Luke Kenneth Casson Leighton, RISC-V ISA Dev
I have to agree with Luke that the writing is unclear.
The fact that the writing in the entire C chapter uses the wording
"C.xyz expands to" is misleading. At the very beginning of this
chapter, it is written:
"RVC was designed under the constraint that each RVC instruction
expands into a single 32-bit instruction ..."
Hence, implementers are given the impression they *must* expand the C
instructions into the ones given as examples in this chapter.
Adding a qualifier at the beginning of a chapter that redefines the
english phrase "expands to" to mean "for example, may expand to", is a
poor and lazy way to write a specification.
Why does this matter? Well, implementing C.MOV as an ADD, ADDI, or OR
instruction can affect which functional unit will be assigned to
execute the code. Implementations should know whether they have
flexibility. The OR implementation would likely use the least power,
for example, and may be preferred by some (especially if the adder is
smaller in width than XLEN, so ADD becomes multi-cycle but OR is still
single-cycle).
Guy
The fact that the writing in the entire C chapter uses the wording
"C.xyz expands to" is misleading. At the very beginning of this
chapter, it is written:
"RVC was designed under the constraint that each RVC instruction
expands into a single 32-bit instruction ..."
Hence, implementers are given the impression they *must* expand the C
instructions into the ones given as examples in this chapter.
Adding a qualifier at the beginning of a chapter that redefines the
english phrase "expands to" to mean "for example, may expand to", is a
poor and lazy way to write a specification.
Why does this matter? Well, implementing C.MOV as an ADD, ADDI, or OR
instruction can affect which functional unit will be assigned to
execute the code. Implementations should know whether they have
flexibility. The OR implementation would likely use the least power,
for example, and may be preferred by some (especially if the adder is
smaller in width than XLEN, so ADD becomes multi-cycle but OR is still
single-cycle).
Guy
> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0CRJMRNA2jBLEW-JeyhYgHpZsOL%3DMDrppoW%3DmmU73_hyw%40mail.gmail.com.
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
Michael Clark
Jun 12, 2018, 9:30:06 PM6/12/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
- MV pseudo is addi r1,r2,0
- C.MV instruction expands to add r1,r2,x0
- a microarchitecture that detects moves in its rename stage needs be aware of this
Some instruction pipelines have an “expand” stage that expands the instruction into an internal micro-op, sometimes with equivalent internal representation to the Base ISA encoding. In this case it makes sense to expand C.MV to ADDI r1,r2,0 ; or to the equivalent internal micro-op with the same side architecture side effects, with the observation that this slight discrepancy exists. The reason for the difference in expansion is due to the bit positions for the register in the compressed instruction so the expansion makes sense, however an OoO processor that does move elimination in its rename stage either needs to alter the expansion or detect two patterns in its “move elimination in rename” stage.
I believe the current text suffices given the commentary mentioning move semantics, where mentioning MV is deliberate. In addition to that, as Andrew mentions; as long as the side effect of the instruction is consistent with that which it must expand to, then the implementation complies and the commentary has additional notes on move detection.
If we were to nitpick we could change “must” to “should”. It is certainly not necessary. C.MV does naturally expand to ADD based on the RVC operand positions.
Jacob Bachmeyer
Jun 12, 2018, 9:37:57 PM6/12/18
to Andrew Waterman, Luke Kenneth Casson Leighton, RISC-V ISA Dev
Andrew Waterman wrote:
> Rather than patching the description of C.MV, I'm proposing the
> following new text in the chapter's introduction:
>
> Throughout this chapter, we prescribe canonical expansions of RVC instructions
> into 32-bit instructions. We briefly note that valid implementations might not
> explicitly expand RVC instructions in this manner.
>
I would suggest slightly different wording:
> Rather than patching the description of C.MV, I'm proposing the
> following new text in the chapter's introduction:
>
> Throughout this chapter, we prescribe canonical expansions of RVC instructions
> into 32-bit instructions. We briefly note that valid implementations might not
> explicitly expand RVC instructions in this manner.
>
"""
Throughout this chapter, we define RVC instructions in terms of
canonical expansions into 32-bit instructions. These expansions are for
notational convenience only. The only requirement on implementations is
that RVC instructions have visible effects equivalent to the defined
canonical expansion with exceptions as noted in the text. The canonical
expansions do not otherwise constrain internal details of valid
implementations.
"""
The "exceptions as noted" cover RVC jump-and-link, which is slightly
different from expanding to JALR. I argue that the important detail is
that the expansions define the semantics of RVC instructions, but do not
otherwise constrain implementations.
-- Jacob
Andrew Waterman
Jun 12, 2018, 9:42:44 PM6/12/18
to Guy Lemieux, Luke Kenneth Casson Leighton, RISC-V ISA Dev
On Tue, Jun 12, 2018 at 6:15 PM, Guy Lemieux <glem...@vectorblox.com> wrote:
> I have to agree with Luke that the writing is unclear.
>
> The fact that the writing in the entire C chapter uses the wording
> "C.xyz expands to" is misleading. At the very beginning of this
> chapter, it is written:
>
> "RVC was designed under the constraint that each RVC instruction
> expands into a single 32-bit instruction ..."
>
> Hence, implementers are given the impression they *must* expand the C
> instructions into the ones given as examples in this chapter.
>
> Adding a qualifier at the beginning of a chapter that redefines the
> english phrase "expands to" to mean "for example, may expand to", is a
> poor and lazy way to write a specification.
That is a valid, if impolitely made, point.
> I have to agree with Luke that the writing is unclear.
>
> The fact that the writing in the entire C chapter uses the wording
> "C.xyz expands to" is misleading. At the very beginning of this
> chapter, it is written:
>
> "RVC was designed under the constraint that each RVC instruction
> expands into a single 32-bit instruction ..."
>
> Hence, implementers are given the impression they *must* expand the C
> instructions into the ones given as examples in this chapter.
>
> Adding a qualifier at the beginning of a chapter that redefines the
> english phrase "expands to" to mean "for example, may expand to", is a
> poor and lazy way to write a specification.
>
> Why does this matter? Well, implementing C.MOV as an ADD, ADDI, or OR
> instruction can affect which functional unit will be assigned to
> execute the code. Implementations should know whether they have
> flexibility. The OR implementation would likely use the least power,
> for example, and may be preferred by some (especially if the adder is
> smaller in width than XLEN, so ADD becomes multi-cycle but OR is still
> single-cycle).
were obvious and did not bear mention.
Luke Kenneth Casson Leighton
Jun 12, 2018, 10:57:07 PM6/12/18
to Andrew Waterman, RISC-V ISA Dev
On Wed, Jun 13, 2018 at 2:14 AM, Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
> On Wed, Jun 13, 2018 at 2:02 AM, Andrew Waterman
> <wate...@eecs.berkeley.edu> wrote:
>> If we were to only write a caveat about C.MV, it would make the manual
>> more confusing, by implying C.MV is special. It's not.
>
> ok so you're saying there's more (which i had missed).
>
> so i'm quite happy to review those as well and comprehensively check
> the language in each case and get back to you. i *believe* the reason
> that i'm picking up on this one is because it's the only one that
> makes the mistake of implying that the (REAL) instruction is a
> pseudo-one.
>
> yeah. i think that's it. without doing a full analysis (yet) i
> think C.MV is the only instruction that i've encountered that is
> actually real.
ok, so apologies for going through this as an inline email (where a
<lk...@lkcl.net> wrote:
> On Wed, Jun 13, 2018 at 2:02 AM, Andrew Waterman
> <wate...@eecs.berkeley.edu> wrote:
>> If we were to only write a caveat about C.MV, it would make the manual
>> more confusing, by implying C.MV is special. It's not.
>
> ok so you're saying there's more (which i had missed).
>
> so i'm quite happy to review those as well and comprehensively check
> the language in each case and get back to you. i *believe* the reason
> that i'm picking up on this one is because it's the only one that
> makes the mistake of implying that the (REAL) instruction is a
> pseudo-one.
>
> yeah. i think that's it. without doing a full analysis (yet) i
> think C.MV is the only instruction that i've encountered that is
> actually real.
static wiki page would be far better).
the context is not that there are pseudo-instructions that are
unclear, but that there are *real* instructions in C that refer *to*
instructions that are "pseudo-implemented". the hypothesis being
tested is that C.MV's language is the only one of these which has:
(a) advice (unclear advice) on what pseudo-instruction to map to
(b) implementation advice for optimising the micro-architecture
as such the confusion stems from the multiple different things that
need to be communicated.
delineated with minuses, conclusion / analysis below
------
13.3 load/store
stack-based: C.SXSP uses language "It expands to sd ..." which itself
is a pseudo that expands to auipc. does not contain implementation
advice. also expansion is unambiguous: no other implementations
really possible anyway.
register-based: C.LX / C.FLX: ditto. uses "it expands to..." a
pseudo-op. ditto no implementation advice. ditto no ambiguity or
choice about what implementors should be doing
13.4 control-transfer
C.J / C.JAL. ditto with the exception that the offset is 2 rather than 4.
C.BEXZ. ditto. still uses "expands to", still expands to a
pseudo-op, (BXX r, x0, offs in this case), still clear, implementors
still nothing but obvious choices about what to do.
13.5 integer computation
integer constant-generation: C.LI ah HA! still uses "expands to",
still expands to a pseudo-op... BUT, just like C.MV, implementations
could hypothetically do something OTHER than "addi, r0, x0, #imm". so
*that's* what this is about... iiiinteresting.
again integer constant-generation: C.LUI: is *NOT* a pseudo-op.
unambiguous and clear.
integer register-immediate ops: C.ADDI/C.SLLI/C.SRRI/C.ANDI/ORI/XORI -
i... think... these ones are ok. not sure. still uses "expands to",
the ops they expand to are definitely not pseudo-ops, however they are
all 2-op (srcreg=destreg) which would give implementors the option to
do some optimisation... howeverrrrr.... chances are that implementors
would do the exact same optimisation in the *non* C variant so i
*believe* all these ones are ok (i.e. unambiguous and clear)
integer register-register ops: C.MV - maps to a pseudo-op, still uses
"expands to". this is the one where there is *more than one way to do
it*, just like C.LI. *that's* what this is about.
again integer register-register ops: C.ADD/OR/SUB/XOR etc - this one
by contrast, you don't do ADD any other way other than "add". clear
and unambiguous implementation, despite being only 2-op.
13.X oink? looks like there's a section-heading missing here called "Misc"
defined illegal instruction: clear. unambiguous.
C.NOP: ah ha! same category as C.MV and C.LI: there are multiple
potential implementations.
breakpoint: clear. unambiguous.
------
ok! so that was really interesting. it's not so much the use of
"expands to" as it is the fact that certain operations have *multiple*
potential implementation possibilities: C.MV, C.NOP and C.LI were the
three that i could identify (and wasn't expecting). all other
instructions are pretty clear (even the 2-op ones of the form "op rd
rd rs"), there's really no other option but to implement the *exact*
advised "expands to ABCXYZ".
C.LI *could* be actually implemented as a *real* "actually put this
constant directly into the register" instruction. C.NOP *could* be
implemented as OR rd, rd, x0, or ANDI rd, rd, #0xfffffffff (maybe) or
XORI rd, rd, #0 or XOR rd, rd, x0 or... as just a genuine actual NOP
which really really does nothing. implementors probably *won't* do
that in the case of C.NOP, but that's not the point.
the other interesting thing is, i now see where you're coming from
with the repeated / regular use of "expands to". however if we look
at the top 3 of table 23.3, "NOP, LI, MV", it's those three that *all*
actually have "myriad sequences" as possible implementations. it's
therefore not a coincidence that i picked up on (one of) them.
now, where this *would not matter at all* is if C did not exist. why?
because as pseudo-ops (and only pseudo-ops) we don't actually care.
it's taken care of by gcc and binutils. implementor doesn't like what
gcc and binutils puts out? no problem, they can change that.
but here, we are talking *REAL* instructions C.MV C.NOP C.LI, where
the spec *explicitly* says *IN HARDWARE* you *MUST* do it *EXACTLY* as
is described.... which for all *other* ops that really doesn't matter
because there is no other choice.
but for these three ops there *are* other options, and that's why the
use of the words "expands to" are not appropriate in these three
(identified) cases *and these cases only*.
whewwww :)
l.
Reply all
Reply to author
Forward
0 new messages