a concern about RISC-V ISA naming

[John Hauser]

The RISC-V unprivileged ISA document recently added this paragraph in
section 28.3, "Instruction-Set Extension Names":

    Some ISA extensions depend on the presence of other extensions,
    e.g., "D" requires "F" and "F" requires "Zicsr".  However, ISA
    strings may not omit the implied extensions, so, for example,
    RV32ID may not be used to imply RV32IFDZicsr.

I wonder if this new rule has consequences that haven't been
considered.  What happens if, in the future, the RISC-V Foundation
wants to standardize subsets of extensions F and D, with, let's say,
names Zfsubset and Zdsubset?  It seems to me that extension F would
then depend on Zfsubset, and D would depend on Zdsubset, just as much
as D depends on F.  After all, what does it mean that "extension x
depends on extension y" other than that y is a subset of x?

Thus, by the simple act of blessing Zfsubset and Zdsubset as standard
extensions, the Foundation would cause previously correct names such
as RV32IFDZicsr to suddenly become wrong.  Instead, the officially
correct name would suddenly change to RV32IFDZicsr_Zfsubset_Zdsubset.
Obviously, this process of name expansion could occur more than once.

Am I the only one who thinks this is a mistake?

In fact, I've always believed the rule should be the opposite:  The
subset extensions can (and normally should) be omitted from the full
name.  So instead of RV32IFDZicsr_Zfsubset_Zdsubset, it's just RV32ID,
with the rest being implied.

The document says it's concerned about the possibility that "the
dependence between extensions could be broken".  However, I'm unable
to construct any scenario where such a change is made less disruptive
because of the current name rule.  If the definition of extension F
is changed so that F is no longer a subset of D, then surely that
has consequences for existing cores which implement F and D under the
old definitions, regardless of whether you call the cores RV32ID or
RV32IFDZicsr.  I.e., if the definition of F changes, then cores that
were earlier called RV32IFDZicsr are no more compatible with the new F
than if they'd been called RV32ID.  So I wonder, what problem is the
current name rule actually solving?

Regards,

    - John Hauser

[Alex Bradbury]

On Thu, 13 Dec 2018, 18:21 John Hauser <jhause...@gmail.com wrote:

The RISC-V unprivileged ISA document recently added this paragraph in
section 28.3, "Instruction-Set Extension Names":

    Some ISA extensions depend on the presence of other extensions,
    e.g., "D" requires "F" and "F" requires "Zicsr".  However, ISA
    strings may not omit the implied extensions, so, for example,
    RV32ID may not be used to imply RV32IFDZicsr.

I wonder if this new rule has consequences that haven't been
considered.  What happens if, in the future, the RISC-V Foundation
wants to standardize subsets of extensions F and D, with, let's say,
names Zfsubset and Zdsubset?  It seems to me that extension F would
then depend on Zfsubset, and D would depend on Zdsubset, just as much
as D depends on F.  After all, what does it mean that "extension x
depends on extension y" other than that y is a subset of x?

Hi John. Thanks for starting this discussion. I think we definitely need to discuss ISA naming string changes in the spec in more detail. Eg I'm concerned about how software  should manage a transition from  accepting -march=rv32imafd to requiring -march=rv32imafd_zicsr_zifencei. To quickly respond to the  particular point you make in the paragraph quoted above: I think there is a difference between "is a subset of" and "depends upon" and the concern you raise could be avoided by simply not declaring F to be dependent on Zfsubset. Do you see a problem with that?

Best,

Alex

Thus, by the simple act of blessing Zfsubset and Zdsubset as standard
extensions, the Foundation would cause previously correct names such
as RV32IFDZicsr to suddenly become wrong.  Instead, the officially
correct name would suddenly change to RV32IFDZicsr_Zfsubset_Zdsubset.
Obviously, this process of name expansion could occur more than once.

Am I the only one who thinks this is a mistake?

In fact, I've always believed the rule should be the opposite:  The
subset extensions can (and normally should) be omitted from the full
name.  So instead of RV32IFDZicsr_Zfsubset_Zdsubset, it's just RV32ID,
with the rest being implied.

The document says it's concerned about the possibility that "the
dependence between extensions could be broken".  However, I'm unable
to construct any scenario where such a change is made less disruptive
because of the current name rule.  If the definition of extension F
is changed so that F is no longer a subset of D, then surely that
has consequences for existing cores which implement F and D under the
old definitions, regardless of whether you call the cores RV32ID or
RV32IFDZicsr.  I.e., if the definition of F changes, then cores that
were earlier called RV32IFDZicsr are no more compatible with the new F
than if they'd been called RV32ID.  So I wonder, what problem is the
current name rule actually solving?

Regards,

    - John Hauser

--
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/ab650d02-cd5d-4447-96c0-6daa9353ddf1%40groups.riscv.org.

[Luke Kenneth Casson Leighton]

On Thu, Dec 13, 2018 at 6:21 PM John Hauser <jhause...@gmail.com> wrote:

> Thus, by the simple act of blessing Zfsubset and Zdsubset as standard
> extensions, the Foundation would cause previously correct names such
> as RV32IFDZicsr to suddenly become wrong. Instead, the officially
> correct name would suddenly change to RV32IFDZicsr_Zfsubset_Zdsubset.
> Obviously, this process of name expansion could occur more than once.
>
> Am I the only one who thinks this is a mistake?

you're not.

standards - if they are to be long-term successful - must have the
following features:

(1) absolutely nothing must be ambiguous.
(2) absolutely nothing must be optional (except through forwards AND
backwards compatible negotiation)
(3) absolutely nothing must be REMOVED from future versions
(4) things may only be ADDED to future versions
(5) if anything is "left to the implementor" (optional extension) it
must not be permitted for there to be optional interactions between
other areas that are also "outside of the remit of the specification".
(specifically, it must be made absolutely clear that doing so will
result in non-conformance)

the area where it sounds like there's a specific problem is (2) as
well as (3). there absolutely has to be a lowest common denominator,
plus a way to say:

* "I am some software. i support these features (bitfield expressing
supported features)"
* "i am some hardware. i support these features (bitfield expressing
availble features)"

the AND of those two bitfields is how forwards- and backwards-
compatibility is achieved, for 20, 30, 40, 50 years.

in other words, there is always, always the possibility of determining
the Lowest Common Denominator.

now, it sounds to me from what you're saying, john, is that there's a
risk of those "bitfields" (features) being replaced by something that
makes it impossible for pre-compiled software to determine the Lowest
Common Denominator, dynamically, at runtime.

to do so is an absolute show-stopper to the long-term viability of the
RISC-V ecosystem. without question.

basically, it's now far too late. you absolutely cannot subset
pre-existing "frozen" functionality and expect the RISC-V standard to
be viable.

i repeat.

you *cannot* subset pre-existing frozen functionality. it is a clear
violation of requirement (3) of successful standards.

this has been discussed before. albert gave the example of how intel
has kept inviolate backwards-compatibility for 3 decades.

l.

[John Hauser]

Alex Bradbury wrote:

To quickly respond to the  particular point you make in the paragraph quoted above: I think there is a difference between "is a subset of" and "depends upon" and the concern you raise could be avoided by simply not declaring F to be dependent on Zfsubset. Do you see a problem with that?

I agree that that's at least viable, and in fact the same occurred
to me as well.  That is, when extension y is a subset of extension x,
the question of whether x depends on y could be just a fiat declaration
of the specifications.  The documents could simply declare that D
"depends on" F, but that F "does not depend on" Zfsubset.

However, it seems the only consequence of this newly conceived
dependence property would be on the ISA strings, which for me begs an
obvious question:  Why bother?  It appears to me that the ISA names
will have fewer complications if the documents simply always declare
that each extension "depends on" no others.  If so, then why not just
dispense with the concept of dependence altogether?

For those who would argue otherwise, I ask that somebody provide an
example of the following:  Assume we have a RISC-V core that implements
RV32IFDZicsr, as it's currently known, but which I'd rather call
"RV32ID".  Sketch out a scenario where, through some sequence of future
events, the name "RV32ID" becomes untenable for this existing core
but the name "RV32IFDZicsr" remains valid, or at least provides some
benefit that I've overlooked.  I think it's going to be impossible for
me to divine the advantage of the current system on my own, without
seeing some specific example given.

Regards,

    - John Hauser

[Andrew Waterman]

You might say it's contrived, but you can imagine a specialized embedded processor that needs double-precision floating-point hardware but has no use for single-precision.  If such a configuration became important enough that we wanted to legalize it, what would we name it?  Obviously, RV32ID wouldn't work, if RV32ID implied F.

I suppose one answer is to assign a new name altogether for that configuration (RV32I_ZDSansF).  That would render moot the remark in the spec that "the dependence between extensions could be broken".

Regards,

    - John Hauser

--
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/905c88f2-155f-4f9a-b00b-80cba713969d%40groups.riscv.org.

[Liviu Ionescu]

> On 13 Dec 2018, at 23:12, Andrew Waterman <and...@sifive.com> wrote:
>
> ... RV32I_ZDSansF

sorry if not directly related to the subject, but how should the compiler generate code for float operations in such a case? use soft float? is it an efficient way to covert between floats and doubles, such that is is better to perform the operations in double and strip the results?


regards,

Liviu

[Andrew Waterman]

I would expect such a platform to define a custom ABI that defines float to be the same type as double.

regards,

Liviu

--
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/CF276108-6A95-4F1E-BC7C-F89120CD6635%40livius.net.

[Jim Wilson]

On Thu, Dec 13, 2018 at 1:35 PM Liviu Ionescu <i...@livius.net> wrote:

> sorry if not directly related to the subject, but how should the compiler generate code for float operations in such a case? use soft float? is it an efficient way to covert between floats and doubles, such that is is better to perform the operations in double and strip the results?

If you convert to double, perform an operation, and then convert back
to float, you will get double rounding errors. The end result will
not be a correct IEEE float result in that case. Soft-float will be
slower, but will give correctly rounded results. Probably best to
give the user an option, and there are actually three options here,
with the third option being to give an error if user code tries to use
float.

Jim

[Liviu Ionescu]

> On 13 Dec 2018, at 23:48, Andrew Waterman <and...@sifive.com> wrote:
>
> ... I would expect such a platform to define a custom ABI that defines float to be the same type as double.

is there any support in the compiler to do so? or a custom compiler is required?

how would debuggers cope with such a situation? for example, is the custom ABI propagated to gdb?


regards,

Liviu

[Andrew Waterman]

I don't know.  It was just a hypothetical example, not something I've investigated at all.

regards,

Liviu

--
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/720D792A-DBF6-421E-BB5C-056A2FEBD23A%40livius.net.

[Jim Wilson]

On Thu, Dec 13, 2018 at 1:55 PM Liviu Ionescu <i...@livius.net> wrote:
> > ... I would expect such a platform to define a custom ABI that defines float to be the same type as double.

Yes, that is another option.

> is there any support in the compiler to do so? or a custom compiler is required?

You just define float as a 64-bit type. In GCC, there is a
FLOAT_TYPE_SIZE macro that each backend has to define, Currently,
all backends define it to 32.

There is an equivalent DOUBLE_TYPE_SIZE for double. Most backends
define this to 64, but a few microcontrollers define it to 32, making
double the same as float.

> how would debuggers cope with such a situation? for example, is the custom ABI propagated to gdb?

If you are using DWARF, then the debug info defines what float means.
The readelf -w output for "float" looks like this
<1><30>: Abbrev Number: 3 (DW_TAG_base_type)
<31> DW_AT_byte_size : 4
<32> DW_AT_encoding : 4 (float)
<33> DW_AT_name : (indirect string, offset: 0x6): float
The byte size is 4 and the encoding is floating-point. Define float
to be the same as double, and the byte size will change to 8 in the
debug info, and gdb will know that all float variables are the same
size as double variables.

Jim

[John Hauser]

Andrew wrote:

You might say it's contrived, but you can imagine a specialized embedded processor that needs double-precision floating-point hardware but has no use for single-precision.  If such a configuration became important enough that we wanted to legalize it, what would we name it?  Obviously, RV32ID wouldn't work, if RV32ID implied F.

Okay, I see your point, but one can well argue that what your proposing
isn't really the same as the D extension as it's currently described,
and hence...

I suppose one answer is to assign a new name altogether for that configuration (RV32I_ZDSansF).  That would render moot the remark in the spec that "the dependence between extensions could be broken".

... a new name seems like a good idea for this case.

Alternatively, a better option for the specific case of F and D might
be this:  In the documents, stop saying that extension D requires
extension F, and leave that instead to the platform specs.  I think the
only detail to sort out would be whether the D extension alone should
imply these instructions:

    FCVT.S.D
    FCVT.D.S
    FLW
    FSW
    FMV.W.X
    FMV.X.W

(My vote is "yes", they are always in D, even without F.)

If the Foundation took this approach, then F and D would be separable
extensions.  Either F or D would necessarily imply Zicsr.  Then,
following my recommended naming rules, you would have "RV32IF" for F
alone, "RV32IFD" for both F and D, but you wouldn't write "RV32IFZicsr"
or "RV32IFDZicsr" because that's both problematic and needlessly
redundant.

The bottom line is, I think there are other ways to deal with this
specific case (and perhaps a few like it), while adopting what I think
are simpler conventions for ISA naming.

Jim Wilson:

If you convert to double, perform an operation, and then convert back
to float, you will get double rounding errors.  The end result will
not be a correct IEEE float result in that case.

Actually, while that sentiment is correct in general, for the specific
instance being discussed (emulating RISC-V's F instructions by
converting single-precision to double, operating in double, and
rounding back to single), double rounding is a risk only for the fused
multiply-add instructions.  For all the other instructions currently
defined for F, you'll always get the correct IEEE answer.

Regards,

    - John Hauser

[John Hauser]

Andrew wrote:

... I would expect such a platform to define a custom ABI that defines float to be the same type as double.

Liviu Ionescu:

is there any support in the compiler to do so? or a custom compiler is required?

Probably not currently.  However, I can attest that the C Standard
officially allows float and double to be the same, and both 64 bits,
so long as your compiler doesn't claim strict IEEE conformance.  Hence,
such a scenario is theoretically not excluded, and I agree with Andrew
that it's at least _plausible_ that somebody might want to do it.  Yes,
they'd be biting off a lot of work for themselves, so it's unlikely
from a practical standpoint.

    - John Hauser

[Bill Huffman]

Hi John,

I think that there's more here than just the names.  If you separate F and D the way you're suggesting, you have to say that three user CSRs (floating point control/status) need to be instantiated by either of F or D but that it's incorrect to make two copies.  It's similar for floating point data registers, but there's the length difference as well.   I'm not saying that such definitions can't be done, just that it adds an additional kind of rule that needs to be considered.  Removing repetition but adding complexity in the working out of rules may not be a good trade-off.

      Bill

--
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/d93b739a-f083-4c33-87a5-6a051bee5d6e%40groups.riscv.org.

[John Hauser]

Bill Huffman wrote:

I think that there's more here than just the names.  If you separate F and D the way you're suggesting, you have to say that three user CSRs (floating point control/status) need to be instantiated by either of F or D but that it's incorrect to make two copies.  It's similar for floating point data registers, but there's the length difference as well.   I'm not saying that such definitions can't be done, just that it adds an additional kind of rule that needs to be considered.  Removing repetition but adding complexity in the working out of rules may not be a good trade-off.

Fair enough, but I was responding to Andrew's stated desire to allow
for this very possibility, that F and D will be separated.  Personally,
I think that's a fine thing to do; however, if the consensus is the
opposite, that separating D from F is too complex, then, as far as this
discussion about ISA naming is concerned, it merely kills off the one
example that Andrew has given for why a core needs to be called RV32IFD
and not RV32ID.

    - John Hauser

[Andrew Waterman]

On Thu, Dec 13, 2018 at 4:20 PM John Hauser <jhause...@gmail.com> wrote:

Andrew wrote:

You might say it's contrived, but you can imagine a specialized embedded processor that needs double-precision floating-point hardware but has no use for single-precision.  If such a configuration became important enough that we wanted to legalize it, what would we name it?  Obviously, RV32ID wouldn't work, if RV32ID implied F.

Okay, I see your point, but one can well argue that what your proposing
isn't really the same as the D extension as it's currently described,
and hence...

I suppose one answer is to assign a new name altogether for that configuration (RV32I_ZDSansF).  That would render moot the remark in the spec that "the dependence between extensions could be broken".

... a new name seems like a good idea for this case.

Alternatively, a better option for the specific case of F and D might
be this:  In the documents, stop saying that extension D requires
extension F, and leave that instead to the platform specs.  I think the
only detail to sort out would be whether the D extension alone should
imply these instructions:

    FCVT.S.D
    FCVT.D.S
    FLW
    FSW
    FMV.W.X
    FMV.X.W

(My vote is "yes", they are always in D, even without F.)

I tentatively agree, but I don't want to get bogged down in defining D-sans-F right now.

If the Foundation took this approach, then F and D would be separable
extensions.  Either F or D would necessarily imply Zicsr.  Then,
following my recommended naming rules, you would have "RV32IF" for F
alone, "RV32IFD" for both F and D, but you wouldn't write "RV32IFZicsr"
or "RV32IFDZicsr" because that's both problematic and needlessly
redundant.

The bottom line is, I think there are other ways to deal with this
specific case (and perhaps a few like it), while adopting what I think
are simpler conventions for ISA naming.

Yeah, I don't have any strong allegiance to one scheme or the other, so maybe we should just optimize for compatibility with previous versions of the ISA-naming scheme.  That would mean that F implies the existence of Zicsr, so RV32IF == RV32IFZicsr.

The case for "D implies F" is less clear w.r.t. compatibility, since the previous versions of the spec don't take a stance as to whether RV32ID == RV32IFD, and current software will reject RV32ID as an invalid ISA.

Jim Wilson:

If you convert to double, perform an operation, and then convert back
to float, you will get double rounding errors.  The end result will
not be a correct IEEE float result in that case.

Actually, while that sentiment is correct in general, for the specific
instance being discussed (emulating RISC-V's F instructions by
converting single-precision to double, operating in double, and
rounding back to single), double rounding is a risk only for the fused
multiply-add instructions.  For all the other instructions currently
defined for F, you'll always get the correct IEEE answer.

Regards,

    - John Hauser

--
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/d93b739a-f083-4c33-87a5-6a051bee5d6e%40groups.riscv.org.

[John Hauser]

I wrote:

Alternatively, a better option for the specific case of F and D might

be this:  In the documents, stop saying that extension D requires
extension F, and leave that instead to the platform specs.  I think the
only detail to sort out would be whether the D extension alone should
imply these instructions:

    FCVT.S.D
    FCVT.D.S
    FLW
    FSW
    FMV.W.X
    FMV.X.W

(My vote is "yes", they are always in D, even without F.)

Andrew:

I tentatively agree, but I don't want to get bogged down in defining D-sans-F right now.

I understand, but I think we can finesse that.  (See below.)

 

Yeah, I don't have any strong allegiance to one scheme or the other, so maybe we should just optimize for compatibility with previous versions of the ISA-naming scheme.  That would mean that F implies the existence of Zicsr, so RV32IF == RV32IFZicsr.

The case for "D implies F" is less clear w.r.t. compatibility, since the previous versions of the spec don't take a stance as to whether RV32ID == RV32IFD, and current software will reject RV32ID as an invalid ISA.

How about this?:

Make a note in the document that, although the D extension is not
currently defined without F, it is intended that a future version of
the specification will define D separate from F (but such that the
combination F + D remains unchanged).  Hence, "D implies F" is only
temporary.  As such, a special case applies that you must write an ISA
string as though D did not imply F, because in the future it won't.

If necessary, change "will define" to "may define", etc.

    - John Hauser

[Luke Kenneth Casson Leighton]

On Thu, Dec 13, 2018 at 9:12 PM Andrew Waterman <and...@sifive.com> wrote:

> You might say it's contrived, but you can imagine a specialized embedded
> processor that needs double-precision floating-point hardware but has
> no use for single-precision.

then that would be a specialist embedded processor that does not
conform to the specification. the normal rules about non-conformance
would apply (i.e. without poisoning the standard for absolutely
everybody else), and the implementor knows full well that they are
taking on full responsibility.

if there are enough of them, they will group together and create an
unofficial platform-specific document, and will also pay for and
maintain the required modifications to the compilers.

at some point they will approach the Foundation and want a standard
put together... and they need to be told *in no uncertain terms* that
their proposal, whilst it can be supported, is a niche
*platform-specific* one that must be firewalled and completely
isolated from the already-frozen spec.

bottom line: it's far far too late to make these kinds of drastic
non-backwards-compatible changes to the spec, andrew. to do so will
f*** everything up for absolutely everybody else.

l.

[Andrew Waterman]

Seems reasonable, I'm moving this to the issue tracker https://github.com/riscv/riscv-isa-manual/issues/307

 

    - John Hauser

--
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/1c3aa2b4-0334-4ea7-9c48-ba818df4c5a5%40groups.riscv.org.

[Luke Kenneth Casson Leighton]

On Fri, Dec 14, 2018 at 4:40 AM Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:
>
>
>
> On Thu, Dec 13, 2018 at 7:34 PM John Hauser <jhause...@gmail.com> wrote:
>> Make a note in the document that, although the D extension is not
>> currently defined without F, it is intended that a future version of
>> the specification will define D separate from F (but such that the
>> combination F + D remains unchanged). Hence, "D implies F" is only
>> temporary. As such, a special case applies that you must write an ISA
>> string as though D did not imply F, because in the future it won't.
>>
>> If necessary, change "will define" to "may define", etc.
>
>
> Seems reasonable, I'm moving this to the issue tracker https://github.com/riscv/riscv-isa-manual/issues/307

i'm not sure if you've seen the messages which indicate that if
RISC-V is to be a long-term successful standard, this is not
reasonable at all.

l.

[Andrew Waterman]

I am not pushing for supporting the D extension in the absence of the F extension.  That was just an example to drive the discussion about what dependences between extensions mean for ISA-name strings.  My proposal is to keep things compatible with the v2.2 spec (Zicsr notwithstanding), and include the conclusion of this discussion in a commentary block.

l.

[Liviu Ionescu]

> On 14 Dec 2018, at 07:17, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:
>
> ... the D extension in the absence of the F extension

can someone estimate what would be the core size reduction in the D without F case?

if it is only a few percents, perhaps it is not worth considering, given the custom toolchain complications.


regards,

Liviu

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Dec 14, 2018 at 5:17 AM Andrew Waterman

<wate...@eecs.berkeley.edu> wrote:
>
>
>
> On Thu, Dec 13, 2018 at 9:00 PM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
>>
>> On Fri, Dec 14, 2018 at 4:40 AM Andrew Waterman
>> <wate...@eecs.berkeley.edu> wrote:
>> >
>> >
>> >
>> > On Thu, Dec 13, 2018 at 7:34 PM John Hauser <jhause...@gmail.com> wrote:
>> >> Make a note in the document that, although the D extension is not
>> >> currently defined without F, it is intended that a future version of
>> >> the specification will define D separate from F (but such that the
>> >> combination F + D remains unchanged). Hence, "D implies F" is only
>> >> temporary. As such, a special case applies that you must write an ISA
>> >> string as though D did not imply F, because in the future it won't.
>> >>
>> >> If necessary, change "will define" to "may define", etc.
>> >
>> >
>> > Seems reasonable, I'm moving this to the issue tracker https://github.com/riscv/riscv-isa-manual/issues/307
>>
>> i'm not sure if you've seen the messages which indicate that if
>> RISC-V is to be a long-term successful standard, this is not
>> reasonable at all.
>
>
> I am not pushing for supporting the D extension in the absence of the F extension. That was just an example to drive the discussion about what dependences between extensions mean for ISA-name strings.

ok thank god for that.

> My proposal is to keep things compatible with the v2.2 spec (Zicsr notwithstanding), and include the conclusion of this discussion in a commentary block.

well, it's "ok", as long as it's kept strictly off of the main
(frozen) standard. i.e. effectively "not officially supported or
sanctioned". however, a place-holder in a *separate*
platform-specific "specialist / niche / embedded" document would be a
much better place.

there, some of the more exotic and rare extensions may at least be
documented, understood, discussed and not need to be repeated for when
every N years another company comes along with the same idea.

as liviu points out, the toolchain complications and significant, and
will wreak havoc on everybody else.

frozen *has* to mean frozen.

l.

[Bruce Hoult]

On Thu, Dec 13, 2018 at 1:49 PM Jim Wilson <ji...@sifive.com> wrote:

On Thu, Dec 13, 2018 at 1:35 PM Liviu Ionescu <i...@livius.net> wrote:
> sorry if not directly related to the subject, but how should the compiler generate code for float operations in such a case? use soft float? is it an efficient way to covert between floats and doubles, such that is is better to perform the operations in double and strip the results?

If you convert to double, perform an operation, and then convert back
to float, you will get double rounding errors.  The end result will
not be a correct IEEE float result in that case.  Soft-float will be
slower, but will give correctly rounded results.

I'm not sure that's correct.

I've seen it stated a number of times [1] that doing a single basic arithmetic operation in double precision FP and then converting it to single precision DOES NOT suffer from errors due to double rounding, PROVIDED that the DP format has more than twice as many mantissa bits as the SP format. This is true for IEEE single (23) and double (53), and is also true for half precision (10) vs single precision, and also for a quarter-precision format with four or fewer bits of mantissa vs half precision.

However I've never seen a proof. So counter-examples are welcome :-)

You can't do a series of operations in double precision before rounding to single. You have to round every time, and then convert back to double for the next operation.

[1] for example Terje Mathisen here https://groups.google.com/d/msg/comp.arch/iUfFfrgAyDI/W55fZHz-Ml0J

 

[Bill Huffman]

Hi Bruce,

I think you are assuming that if you take two single-precision floating-point numbers, convert to double precision, do an add/sub/mul/div operation in double-precision (in any rounding mode) then convert back to single-precision (with the same round mode), you will get the single-precision answer.  I don't have a counter example here.

I don't think you meant you could start with any double-precision floating-point operands, operate and round.

More seriously, I don't think this works for FMA operations for much the same reason it doesn't work if you do more than one operation without rounding.  More specifically, I think you can get a pre-rounding FMA result to be very near the single-precision-half-ulp point and have the double precision round take it to exactly the single-precision-half-ulp point where round-to-even then takes it the wrong way on convert to single.

If it, indeed, doesn't work for FMA, that would be important in the RISC-V floating-point.

      Bill

--
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/CAP8PnuSRK2nuJ1mh4Q0ErVR8n5fGPeDARdsgjYLygqfs5SKkuQ%40mail.gmail.com.

[Andrew Waterman]

On Fri, Dec 14, 2018 at 4:30 PM Bill Huffman <huf...@cadence.com> wrote:

Hi Bruce,

I think you are assuming that if you take two single-precision floating-point numbers, convert to double precision, do an add/sub/mul/div operation in double-precision (in any rounding mode) then convert back to single-precision (with the same round mode), you will get the single-precision answer.  I don't have a counter example here.

I don't think you meant you could start with any double-precision floating-point operands, operate and round.

More seriously, I don't think this works for FMA operations for much the same reason it doesn't work if you do more than one operation without rounding.  More specifically, I think you can get a pre-rounding FMA result to be very near the single-precision-half-ulp point and have the double precision round take it to exactly the single-precision-half-ulp point where round-to-even then takes it the wrong way on convert to single.

If it, indeed, doesn't work for FMA, that would be important in the RISC-V floating-point.

Earlier in the thread, John Hauser, who's one of the experts on matters IEEE-754, confirmed what you wrote: FMA will not be correctly rounded in general, but all of the other operations will be correctly rounded.

[kr...@berkeley.edu]

Any future "D without F" should be given a different name (Zdnof?)
instead of redefining D, if for no other reason, than it will require
some different set of operations than current D minus F (e.g., FLW/FSW
as JohnH mentions).

Given that current D requires/implies all of F, could shorten
canonical string in this case.

Krste

| --
| 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%2B6G0Dhvdw%3Dkh%3Dziki-uGY4p0bnvhznJEPLswEaRqFGVPy34Q%40mail.gmail.com
| .

[Luke Kenneth Casson Leighton]

On Tue, Dec 18, 2018 at 11:19 AM <kr...@berkeley.edu> wrote:

> Any future "D without F" should be given a different name (Zdnof?)
> instead of redefining D, if for no other reason, than it will require
> some different set of operations than current D minus F (e.g., FLW/FSW
> as JohnH mentions).

the naming doesn't matter at all: it's the fact that it's a
non-backwards-compatible drastic change to the standard that matters.
such a change (whatever the name) should have been proposed,
discussed, and ratified well over two years ago, when the D and F
standards were not frozen.

it's far, far too late to begin discussing these as *mainstream*
standards, now (because they are not backwards-compatible changes).
as such they need to be absolutely firewalled well away from everybody
in the entire mainstream standards process, as "platform-specific"
augmentations.

l.