Initial base for AltFP #2

kdockser · 2022-02-25T22:10:48Z

Define RISC-V version of BF16 format and behaviors

Inital draft

…to working

nibrunieAtSi5 · 2022-02-26T00:53:49Z

I am not sure the .DS_store file attached to this PR was intended.

doc/riscv-bfloat16-appx-rationale.adoc

doc/riscv-bfloat16-format.adoc

nibrunieAtSi5 · 2022-02-26T01:01:46Z

doc/riscv-bfloat16-introduction.adoc

+
+Experts working in machine learning noticed that FP16 was a much more compact way of
+storing operands and often provided sufficient precision for them. However, they also
+found that intermediate values were much better when accumulated into a higher precision.


does better means accuracte here ?

Yes, it does. I will clarify and elaborate (a little). Also, thanks for catching the typos.

Co-authored-by: Nicolas Brunie <[email protected]>

tovine

Looks like a good start for a proposal, keep up the good work! 😄

tovine · 2022-03-04T09:16:45Z

doc/riscv-bfloat16-appx-rationale.adoc

+
+Fused multiply add.
+
+=== Dot Product


Is the intention here to support dot product as a packed-SIMD style operation, or an application of FMA?

Upon reading the rest of the spec, it seems like this is intended to be used in packed-SIMD style ops. The spec should probably also define other operations on multiple packed BF16 operands (at least a note on how to load/store them - probably using standard FLW/FLD?) and how this is intended to work in general; I assume it's useful to to think about this for all operations, since just using 16 bits of a 32 or 64 bit register seems a bit wasteful.

Yes, the intention is for dot product operations, as that is what BF16 is usually used for. It was requested that we start with the base and then we can move on to operations. I anticipate that these operations will be most useful in Vector.

tovine · 2022-03-04T09:22:48Z

doc/riscv-bfloat16-format.adoc

+|FP16    |1| 8| 7| 0|16| 127|-126
+|BFloat16|1| 5|10| 0|16|  15| -14


I think you got these switched around: BF16 is the same as FP32, but with 16 fewer fraction bits: https://cloud.google.com/blog/products/ai-machine-learning/bfloat16-the-secret-to-high-performance-on-cloud-tpus

You are correct. Somehow I swapped them.

tovine · 2022-03-04T09:25:15Z

doc/riscv-bfloat16-format.adoc

+|FP16    |1| 8| 7| 0|16| 127|-126
+|BFloat16|1| 5|10| 0|16|  15| -14
+|TF32    |1| 8|10|13|32| 127|-126
+|FP32    |1| 9|23| 0|32| 127|-126


FP32 only has 8 exponent bits, not 9 - as it's written now the sum of bits would be 33.
There is an implied 1 bit in there so technically you get the effect of 33 bits, but that goes into the fraction 🙂

Thanks for catching the typo. I will fix.

tovine · 2022-03-04T09:49:14Z

Have you considered any synergy effects between this extension and the P (Packed SIMD) proposal? BF16 is definitely a good candidate for that, so this should probably be discussed in the spec somewhere. Especially with the mention of dot product operations

allenjbaum · 2022-03-04T17:39:35Z

I also noticed the statements: "Instruction design and definition. (This part has dependency on Zfh & RVV & EDIV.)" and "Additional vector extension/ EDIV extension operations;"

you left out ZHinx (or ZFinx, or both) as well as P-extension (in RV64, at least).
in the interests of not "boiling the ocean" I would think it would be prudent to neither rely on nor consider defining anything that depends on RVV for now - and especially not EDIV which is not official in any sense. That should be a separate TG.
I am guessing that you just want to make sure that this might be extended_to / supportable_by a vector implementation - and that you're not trying to define those here - but that should be clear and explicit.

allenjbaum · 2022-03-04T18:15:11Z

NaNs
You say you're supporting signaling Nans, but no operation will produce them.
Does that mean if one is loaded into a register, despite not being produced by an fp16 op,
and subsequently used by an fp16 op, it will be treated as a quiet NaN? (i.e. no trap)
I actually don't know what IEEE says about that particular case.

denorms
The charter mentions "Handling flush-to-zero for IEEE types and BF16 type." but the format doc simply states that all denormals are flushed to zero. So are you making flush-to-zero configurable? OR is this strictly how you handle conversions for IEEE denormals to bf16, or something else?

Also: you say "Furthermore, with BFloat16’s relatively large exponent range, subnormals add little value."
except there is only a 5bit exponent field, smaller than any other format listed. How can you call this "large"?

Exceptions:
the statement is confusing in that the first sentence mentions exceptions, and the second status, with nothing that connects them. Specifically, it doesn't mention that RISC-V never takes an exception for an operation regardless or result or input operand, and so (insert second sentence here)

In the Policies doc, you say:
"higher effective storage bandwidth - Two BFloat16 operands can be transferred at the same rate as one FP32
higher computational throughput - Two BFloat16 multiplies can be performed with less logic than one FP32"
This implies that you're using packed SIMD. IS that being proposed at all? Otherwise, you highly unlikely to get any better throughput, and you can get better load store bandwidth, but you need to add extra pack/unpack operations, which decreases throughput, at least.

kdockser · 2022-03-04T18:15:56Z

Thanks Allen, The intention is for this to be the base behavior for BF16 in all of RISC-V. This allows results to be shared between, for example, scalar floating-point and vector. I don't think that the P-extension includes floating-point. In any case, I think BF16 will see more use in the V-extension as it is commonly used in high-performance matrix operations. I'll add the missing references. Based on Krste's comments in another thread, it seems that EDIV is no longer under consideration and there are newer better approaches that will be proposed for vector-based matrix operations. Thanks, Ken

…

On Fri, Mar 4, 2022 at 11:39 AM Allen Baum ***@***.***> wrote: I also noticed the statements: "Instruction design and definition. (This part has dependency on Zfh & RVV & EDIV.)" and "Additional vector extension/ EDIV extension operations;" 1. you left out ZHinx (or ZFinx, or both) as well as P-extension (in RV64, at least). 2. in the interests of not "boiling the ocean" I would think it would be prudent to neither rely on nor consider defining anything that depends on RVV for now - and especially not EDIV which is not official in any sense. That should be a separate TG. I am guessing that you just want to make sure that this might be extended_to / supportable_by a vector implementation - and that you're not trying to define those here - but that should be clear and explicit. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI6QBRUDKMX6MUFB5KVHN2TU6JDGHANCNFSM5PLM7QJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

kdockser · 2022-03-04T18:58:36Z

On Fri, Mar 4, 2022 at 12:15 PM Allen Baum ***@***.***> wrote: *NaNs* You say you're supporting signaling Nans, but no operation will produce them.

[KAD] Yes, IEEE-754 states that no operation will produce an SNaN. They can be provided by the user, for example as uninitialized data.

Does that mean if one is loaded into a register, despite not being produced by an fp16 op, and subsequently used by an fp16 op, it will be treated as a quiet NaN? (i.e. no trap) I actually don't know what IEEE says about that particular case.

[KAD] IEEE Std 754™-2019 says that "any general-computational operation on a signaling NaN" causes an invalid operation. We will follow this behavior.

*denorms* The charter mentions "Handling flush-to-zero for IEEE types and BF16 type." but the format doc simply states that all denormals are flushed to zero. So are you making flush-to-zero configurable? OR is this strictly how you handle conversions for IEEE denormals to bf16, or something else?

[KAD] The proposal is for subnormal BF16 inputs to be treated as properly signed zeros and for subnormal outputs to be flushed to a properly signed zero. There is no configuration.

Also: you say "Furthermore, with BFloat16’s relatively large exponent range, subnormals add little value." except there is only a 5bit exponent field, smaller than any other format listed. How can you call this "large"?

[KAD] That was a typo on my part. BFloat16 uses the same 8-bit exponent as FP32.

*Exceptions*: the statement is confusing in that the first sentence mentions exceptions, and the second status, with nothing that connects them. Specifically, it doesn't mention that RISC-V never takes an exception for an operation regardless or result or input operand, and so (insert second sentence here)

[KAD] I'm not sure what text you are talking about. Are you conflating exceptions with exceptions with traps? RISC-V reports floating-point exceptions via the exception flags. It does not take traps due to floating-point exceptions.

In the Policies doc, you say: "higher effective storage bandwidth - Two BFloat16 operands can be transferred at the same rate as one FP32 higher computational throughput - Two BFloat16 multiplies can be performed with less logic than one FP32" This implies that you're using packed SIMD. IS that being proposed at all? Otherwise, you highly unlikely to get any better throughput, and you can get better load store bandwidth, but you need to add extra pack/unpack operations, which decreases throughput, at least.

[KAD] Typically, BF16 is used in widening dot product operations - this is where they earn their keep. However, I was asked to address the base part first. Once we have consensus on the base we can move to instructions.

…

Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI6QBRVXYTVEZSVWASPWODDU6JHL3ANCNFSM5PLM7QJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

aswaterman · 2022-03-04T21:45:50Z

Flushing subnormals to zero should be a property of an operation, not a property of the format. The format can clearly define what the subnormal values mean, and specific operations can choose to interpret them as zero and flush outputs to zero. This approach better separates concerns.

Some other architectures’ BF16 instructions only flush subnormals in some instructions (e.g. dot product flushes to zero, but conversion to and from FP32 does not, since flushing in the latter case doesn’t buy you anything). We don’t need to wade into that debate today, but we do need to preserve the possibility of having that debate by removing the flush-to-zero mandate from the format definition.

kdockser · 2022-03-04T22:57:54Z

Thanks Andrew, I agree that it doesn't necessarily make sense to flush to zero on conversions and that there might be other instructions where flushing doesn't make sense. I put the flush-to-zero as part of the format because I was told that we need to agree on the base before we can move forward on discussing instructions. I will revise the wording to indicate that such flushing is the general intention but for a limited set of instructions (which are TBD) it might not be the rule. Ken

…

On Fri, Mar 4, 2022 at 3:46 PM Andrew Waterman ***@***.***> wrote: Flushing subnormals to zero should be a property of an operation, not a property of the format. The format can clearly define what the subnormal values mean, and specific operations can choose to interpret them as zero and flush outputs to zero. This approach better separates concerns. Some other architectures’ BF16 instructions only flush subnormals in some instructions (e.g. dot product flushes to zero, but conversion to and from FP32 does not, since flushing in the latter case doesn’t buy you anything). We don’t need to wade into that debate today, but we do need to preserve the possibility of having that debate by removing the flush-to-zero mandate from the format definition. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI6QBRW2COWAV6W2TAJXNXDU6KAB7ANCNFSM5PLM7QJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

allenjbaum · 2022-03-04T22:58:14Z

Apologies to all - my comments were referencing an old document that I managed to stumble on, not the charter document.

…

On Fri, Mar 4, 2022 at 1:46 PM Andrew Waterman ***@***.***> wrote: Flushing subnormals to zero should be a property of an operation, not a property of the format. The format can clearly define what the subnormal values mean, and specific operations can choose to interpret them as zero and flush outputs to zero. This approach better separates concerns. Some other architectures’ BF16 instructions only flush subnormals in some instructions (e.g. dot product flushes to zero, but conversion to and from FP32 does not, since flushing in the latter case doesn’t buy you anything). We don’t need to wade into that debate today, but we do need to preserve the possibility of having that debate by removing the flush-to-zero mandate from the format definition. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTVJA7UQIADFIRKPO3U6KAB7ANCNFSM5PLM7QJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

doc/riscv-bfloat16-appx-rationale.adoc

nibrunieAtSi5 · 2022-04-04T21:36:51Z

doc/riscv-bfloat16-appx-rationale.adoc

+(Single Precision).
+
+We chose not to have direct conversion between BFloa16 and other formats as they
+can typically be performed by a combination of instructions. 


Do we intend to list (and check) those combinations of instructions in the actual specification ?

We intend to check that it is possible to move between these other formats. This would likely be in an appendix rather than as a part of the specification proper.

doc/riscv-bfloat16-appx-rationale.adoc

nibrunieAtSi5 · 2022-04-04T21:41:39Z

doc/riscv-bfloat16-format.adoc

+Floating-point values that are too small to be represented as normal numbers, but can still be represented by using the format's smallest exponent with a zero integer bit and one or more leading 0s --- and one or
+
+more 1s --- in the trailing fractional bits are called subnormal numbers. Basically, the idea is there is


Suggested change

Floating-point values that are too small to be represented as normal numbers, but can still be represented by using the format's smallest exponent with a zero integer bit and one or more leading 0s --- and one or

more 1s --- in the trailing fractional bits are called subnormal numbers. Basically, the idea is there is

Floating-point values that are too small to be represented as normal numbers, but can still be represented by using the format's smallest exponent with a zero integer bit and one or more leading 0s --- and one or

more 1s --- in the trailing fractional bits are called subnormal numbers. Basically, the idea is there is

Thanks for catching. I fixed this but hadn't added it before committing. The latest pull request should look better (for this file anyway).

No problem, I am trying to do a full review and listing typos / questions along the way.

nibrunieAtSi5 · 2022-04-04T21:42:33Z

doc/riscv-bfloat16-format.adoc

+a trade off of precision to support _gradual underflow_.
+
+In RISC-V instructions operating on BFloat16, it is generally intended that all subnormal BFloat16 inputs are treated as zero and subnormal outputs are flushed to zero. The sign of the original value is retained. However, it
+is uop to the instruction to specify this behavior. 


Suggested change

is uop to the instruction to specify this behavior.

is up to the instruction to specify this behavior.

nibrunieAtSi5 · 2022-04-04T21:44:42Z

doc/riscv-bfloat16-format.adoc

+vary based on the instruction as there are special cases where it may be undesirable to 
+some special cases where it is not desirable to treat 
+This is not consistent with '754' but has been found to be a suitable alternative in many workloads. Furthermore, with BFloat16's relatively large exponent range, subnormals add little value.


Suggested change

vary based on the instruction as there are special cases where it may be undesirable to

some special cases where it is not desirable to treat

This is not consistent with '754' but has been found to be a suitable alternative in many workloads. Furthermore, with BFloat16's relatively large exponent range, subnormals add little value.

This behavior may vary based on the instruction as there are special cases where it may be undesirable to treat subnormals as zero.

This is not consistent with '754' but has been found to be a suitable alternative in many workloads. Furthermore, with BFloat16's relatively large exponent range, subnormals add little value.

nibrunieAtSi5 · 2022-04-04T21:53:27Z

doc/riscv-bfloat16-format.adoc

+In general, the default IEEE rounding mode (round to nearest, ties to even) works for arithmetic cases. There are some special cases where a particular instruction benefits from a different rounding mode (e.g., convert to integer, widening multiply-accumulate) - we can address this on those specific instructions.
+


Does this mean we intend to have a static rounding mode force to RNE by default and only allow rounding-mode static (opcode) or dynamic (csr) selection on a specific subset of instructions ? This seems to be in contradiction with F and D extensions and should be justified here IMHO.

Yes, these instructions would have a static rounding mode that is not overridable. Yes, this is different from '754. However, it is a common simplification (just like flushing subnormals). If someone needs more control over the rounding mode they can run in SP (F).

I agree that we will need to provide a detailed justification in the specification for this simplification.

nibrunieAtSi5 · 2022-04-04T21:54:25Z

doc/riscv-bfloat16-format.adoc

+In general, the default IEEE rounding mode (round to nearest, ties to even) works for arithmetic cases. There are some special cases where a particular instruction benefits from a different rounding mode (e.g., convert to integer, widening multiply-accumulate) - we can address this on those specific instructions.
+
+=== Handling exceptions
+Default exception handling, as defined by IEEE, is a simple and effective approach to producing results in exceptional cases. For the coder to be able to see what has happened, and take further action if needed, the BFloat16 instructions need to set floating-point exception flags the same way as all other floating-point instructions in RISC-V. 


This formulation may not be future proof, we may want to cite explicitly the basic floating-point extensions here.

Which area are concerned about: the rounding mode, default exception handling, or both?

Should the need arise, an extension could be added that allows the rounding mode to be changed by the CSR.

The handling of exceptions via the IEEE default is common across RISC-V. Is this what you mean about citing the basic floating-point extensions?
At some point there might be a TG that creates trapped exceptions for FP instructions - but right now only default is supported.

I am concerned that another floating-point extension may be introduced with a different way of managing FP exception flags, making "as all other floating-point instructions ..." missleading. So mentioning explicitly that we intend to managed them as extension F and D (and Q), clarifies things if such an extension should appear at some point. I agree that the use of such remark may be limited.

Co-authored-by: Nicolas Brunie <[email protected]>

nibrunieAtSi5 · 2022-04-04T22:03:56Z

doc/riscv-bfloat16-policies.adoc

+benefits of the BFloat16 format +
+** reduced storage space - A BFloat16 operand consumes half the space of an FP32 operand +
+** higher effective storage bandwidth - Two BFloat16 operands can be transferred at the same rate as one FP32 +
+** higher computational throughput - Two BFloat16 multiplies can be performed with less logic than one FP32 +


We could even add than one BFloat16 multiply can be done with less logic than one FP16 (mostly due to multiplier area gains)

doc/riscv-bfloat16-spec.adoc

Co-authored-by: Nicolas Brunie <[email protected]>

tovine · 2022-04-05T01:45:14Z

This might not be in the scope for this extension, but have you considered unum/posit?

allenjbaum · 2022-04-05T04:42:22Z

+...Signalling NaNs are provided as input data since no computational instruction will ever produce this kind of a NaN. I would add **ony** to this: +...Signalling NaNs are provided as input data **only*** since no computational instruction will ever produce this kind of a NaN. +...Operating on a Quiet NaN usually does not cause an exception. The word "usually" is uncommonly vague here. Does that mean it depends on the op, the other bits in the Nan operand, the value of the other operand, the rounding more, the phase of the moon, or what?

…

On Mon, Apr 4, 2022 at 3:22 PM Nicolas Brunie ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In doc/riscv-bfloat16-format.adoc <#2 (comment)>: > + +NaN stands for Not a Number. These are provided as the result of an operation when it cannot be represented +as a number or infinity. For example, performing the square root of -1 will result in a NaN because +there is no real number that can represent the result. NaNs can also be used as inputs. + +There are two types of NaNs: signalling and quiet. Signalling NaNs are provided as input data since no computational instruction will ever produce this kind of a NaN. Operating on a Signalling NaN will produce an invalid operation exception. Operating on a Quiet NaN usually does not cause an exception. + +NaNs include a sign bit, but the bit has no meaning. + +NaNs are important for keeping meaningless results from being operated upon. It is best to retain them. As IEEE allows, operations should return the canonical NaN rather than be required to propagate the payload. + +=== Rounding Modes: +In general, the default IEEE rounding mode (round to nearest, ties to even) works for arithmetic cases. There are some special cases where a particular instruction benefits from a different rounding mode (e.g., convert to integer, widening multiply-accumulate) - we can address this on those specific instructions. + +=== Handling exceptions +Default exception handling, as defined by IEEE, is a simple and effective approach to producing results in exceptional cases. For the coder to be able to see what has happened, and take further action if needed, the BFloat16 instructions need to set floating-point exception flags the same way as all other floating-point instructions in RISC-V. I am concerned that another floating-point extension may be introduced with a different way of managing FP exception flags, making "as all other floating-point instructions ..." missleading. So mentioning explicitly that we intend to managed them as extension F and D (and Q), clarifies things if such an extension should appear at some point. I agree that the use of such remark may be limited. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJU2RMD2GLYSIXI4MALVDNTRNANCNFSM5PLM7QJA> . You are receiving this because you commented.Message ID: ***@***.***>

kdockser · 2022-04-07T16:44:32Z

Hi Torbjørn, You are correct in that this is out of scope for this BFloat16 extension. However, it is not out of scope for the broader AltFP group. So, unums/posits could be considered for subsequent extensions under AltFP.

…

-Ken

On Mon, Apr 4, 2022 at 8:45 PM Torbjørn Viem Ness ***@***.***> wrote: This might not be in the scope for this extension, but have you considered unum/posit? — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI6QBRX2YRODVBS6SBBW4LDVDOLLLANCNFSM5PLM7QJA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

kdockser · 2022-04-07T16:51:20Z

Thanks Allen, I agree, the sentence is missing an "only". I'll add it in. I'll add some more text to generally explain where an input QNaN could cause an exception with more details in subsequent text. Thanks, Ken

…

On Mon, Apr 4, 2022 at 11:42 PM Allen Baum ***@***.***> wrote: +...Signalling NaNs are provided as input data since no computational instruction will ever produce this kind of a NaN. I would add **ony** to this: +...Signalling NaNs are provided as input data **only*** since no computational instruction will ever produce this kind of a NaN. +...Operating on a Quiet NaN usually does not cause an exception. The word "usually" is uncommonly vague here. Does that mean it depends on the op, the other bits in the Nan operand, the value of the other operand, the rounding more, the phase of the moon, or what? On Mon, Apr 4, 2022 at 3:22 PM Nicolas Brunie ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In doc/riscv-bfloat16-format.adoc > <#2 (comment)>: > > > + > +NaN stands for Not a Number. These are provided as the result of an operation when it cannot be represented > +as a number or infinity. For example, performing the square root of -1 will result in a NaN because > +there is no real number that can represent the result. NaNs can also be used as inputs. > + > +There are two types of NaNs: signalling and quiet. Signalling NaNs are provided as input data since no computational instruction will ever produce this kind of a NaN. Operating on a Signalling NaN will produce an invalid operation exception. Operating on a Quiet NaN usually does not cause an exception. > + > +NaNs include a sign bit, but the bit has no meaning. > + > +NaNs are important for keeping meaningless results from being operated upon. It is best to retain them. As IEEE allows, operations should return the canonical NaN rather than be required to propagate the payload. > + > +=== Rounding Modes: > +In general, the default IEEE rounding mode (round to nearest, ties to even) works for arithmetic cases. There are some special cases where a particular instruction benefits from a different rounding mode (e.g., convert to integer, widening multiply-accumulate) - we can address this on those specific instructions. > + > +=== Handling exceptions > +Default exception handling, as defined by IEEE, is a simple and effective approach to producing results in exceptional cases. For the coder to be able to see what has happened, and take further action if needed, the BFloat16 instructions need to set floating-point exception flags the same way as all other floating-point instructions in RISC-V. > > I am concerned that another floating-point extension may be introduced > with a different way of managing FP exception flags, making "as all other > floating-point instructions ..." missleading. So mentioning explicitly that > we intend to managed them as extension F and D (and Q), clarifies things if > such an extension should appear at some point. I agree that the use of such > remark may be limited. > > — > Reply to this email directly, view it on GitHub > <#2 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AHPXVJU2RMD2GLYSIXI4MALVDNTRNANCNFSM5PLM7QJA > > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI6QBRVNFFSFGDLWCLVGAA3VDPADTANCNFSM5PLM7QJA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Fix bfloat16 and fp16 rows in fp-table

kdockser and others added 3 commits February 25, 2022 16:09

Add files via upload

44bf540

Inital draft

Work

f94139b

Merge branch 'working' of https://github.com/kdockser/riscv-alt-fp in…

f5d13d8

…to working

nibrunieAtSi5 reviewed Feb 26, 2022

View reviewed changes

doc/riscv-bfloat16-appx-rationale.adoc Outdated Show resolved Hide resolved

nibrunieAtSi5 reviewed Feb 26, 2022

View reviewed changes

doc/riscv-bfloat16-format.adoc Outdated Show resolved Hide resolved

nibrunieAtSi5 reviewed Feb 26, 2022

View reviewed changes

doc/riscv-bfloat16-format.adoc Outdated Show resolved Hide resolved

nibrunieAtSi5 reviewed Feb 26, 2022

View reviewed changes

doc/riscv-bfloat16-format.adoc Outdated Show resolved Hide resolved

nibrunieAtSi5 reviewed Feb 26, 2022

View reviewed changes

kdockser and others added 5 commits February 26, 2022 17:07

Update doc/riscv-bfloat16-format.adoc

ab80f72

Co-authored-by: Nicolas Brunie <[email protected]>

Update doc/riscv-bfloat16-format.adoc

3f10a10

Co-authored-by: Nicolas Brunie <[email protected]>

Update doc/riscv-bfloat16-format.adoc

4b497d6

Co-authored-by: Nicolas Brunie <[email protected]>

Update doc/riscv-bfloat16-appx-rationale.adoc

12516a6

Co-authored-by: Nicolas Brunie <[email protected]>

removed stowaway.

d89b343

tovine reviewed Mar 4, 2022

View reviewed changes

kdockser added 2 commits April 4, 2022 15:39

Cleanup and clarification

a55b8d4

Cleanup and clarification of initial draft.

52777c4

nibrunieAtSi5 reviewed Apr 4, 2022

View reviewed changes

doc/riscv-bfloat16-appx-rationale.adoc Outdated Show resolved Hide resolved

nibrunieAtSi5 reviewed Apr 4, 2022

View reviewed changes

doc/riscv-bfloat16-appx-rationale.adoc Outdated Show resolved Hide resolved

nibrunieAtSi5 reviewed Apr 4, 2022

View reviewed changes

kdockser and others added 3 commits April 4, 2022 16:57

A couple of cleanups didn't make it through...

29cb303

Update doc/riscv-bfloat16-appx-rationale.adoc

1c0f957

Co-authored-by: Nicolas Brunie <[email protected]>

Update doc/riscv-bfloat16-appx-rationale.adoc

1e65e82

Co-authored-by: Nicolas Brunie <[email protected]>

nibrunieAtSi5 reviewed Apr 4, 2022

View reviewed changes

doc/riscv-bfloat16-spec.adoc Outdated Show resolved Hide resolved

Update doc/riscv-bfloat16-spec.adoc

cf2e130

Co-authored-by: Nicolas Brunie <[email protected]>

Achierius and others added 2 commits April 11, 2022 13:08

un-flip bfloat16 and fp16 rows in fp-table

0269541

Merge pull request #1 from Achierius/patch-1

e5201c5

Fix bfloat16 and fp16 rows in fp-table

		\|FP16 \|1\| 8\| 7\| 0\|16\| 127\|-126
		\|BFloat16\|1\| 5\|10\| 0\|16\| 15\| -14

		Floating-point values that are too small to be represented as normal numbers, but can still be represented by using the format's smallest exponent with a zero integer bit and one or more leading 0s --- and one or

		more 1s --- in the trailing fractional bits are called subnormal numbers. Basically, the idea is there is

	is uop to the instruction to specify this behavior.
	is up to the instruction to specify this behavior.

		In general, the default IEEE rounding mode (round to nearest, ties to even) works for arithmetic cases. There are some special cases where a particular instruction benefits from a different rounding mode (e.g., convert to integer, widening multiply-accumulate) - we can address this on those specific instructions.

Initial base for AltFP #2

Are you sure you want to change the base?

Initial base for AltFP #2

Conversation

kdockser commented Feb 25, 2022

nibrunieAtSi5 commented Feb 26, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tovine left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tovine commented Mar 4, 2022

allenjbaum commented Mar 4, 2022

allenjbaum commented Mar 4, 2022

kdockser commented Mar 4, 2022 via email

kdockser commented Mar 4, 2022 via email

aswaterman commented Mar 4, 2022

kdockser commented Mar 4, 2022 via email

allenjbaum commented Mar 4, 2022 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tovine commented Apr 5, 2022

allenjbaum commented Apr 5, 2022 via email

kdockser commented Apr 7, 2022 via email

kdockser commented Apr 7, 2022 via email