FP16 extension

[joxie xie]

Hello RISC-V community,

We are evaluating if a RISC-V processor can be used in deep learning use cases, for deep learning a FP16 is already good enough. AFAIK ARM provides instructions to convert between FP16 and FP32 in VFPV3, I was wondering why RISC-V does not have something similar, an extension with FP16 instructions would be even better for small implementations using compressed ISA.

Any thoughts?

-Thanks

[kr...@berkeley.edu]

FP16 is added as part of the V vector spec.


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/
| CAGBX-%3DBHa3VmNKbqK6W8dB7kwCHvXEHY65k3XfGYrLSc5P3n3A%40mail.gmail.com.

[Po-wei Huang]

Hi Krste,
Why don’t we decouple FP16 from vector, as it should be a stand alone extension.
Best,
Po-wei

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/22784.25640.545433.712308%40KAMacBookPro2016.local.

[joxie xie]

Ah, I missed that. :)

2017-04-26 17:12 GMT+08:00 Po-wei Huang <poweih...@gmail.com>:

Hi Krste,
Why don’t we decouple FP16 from vector, as it should be a stand alone extension.
Best,
Po-wei

> kr...@berkeley.edu 於 2017年4月26日 下午5:11 寫道：
>
>
> FP16 is added as part of the V vector spec.
>
>
> Krste
>
>>>>>> On Wed, 26 Apr 2017 17:10:20 +0800, joxie xie <tshm...@gmail.com> said:
>
> | Hello RISC-V community,
> | We are evaluating if a RISC-V processor can be used in deep learning use cases,
> | for deep learning a FP16 is already good enough. AFAIK ARM provides
> | instructions to convert between FP16 and FP32 in VFPV3, I was wondering why
> | RISC-V does not have something similar, an extension with FP16 instructions
> | would be even better for small implementations using compressed ISA.
>
> | Any thoughts?
>
> | -Thanks
>
> | --
> | 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+unsubscribe@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/
> | CAGBX-%3DBHa3VmNKbqK6W8dB7kwCHvXEHY65k3XfGYrLSc5P3n3A%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+unsubscribe@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/.

[kr...@berkeley.edu]

Rationale in start of vector spec:

"We only support scalar half-precision floating-point types as part of
the vector extension, as the main benefits of half-precision are
obtained when using vector instructions that amortize per-operation
control overhead. Not supporting a separate scalar half-precision
floating-point extension also reduces the number of standard
instruction-set variants."

We could imagine separating out an extension that was just the scalar
half-precision instructions, as I guess there is also the benefit of
reduced dataset size, but once you have 16-bit operands, you really
want SIMD execution to take advantage of datapaths that will be at
least 32-bits wide in a RISC-V system. Also, most apps that want
16-bit floats really need at least 32-bit floats for accumulators.
The minimal vector extension does not require much state or logic on
top of systems with 16/32-bit

Krste

[Bruce Hoult]

Hi Po-wei, "should", why?

On the plus side there is obviously an argument from orthogonality.

On the minus side there is the danger of an explosion of the number of combinations of extensions. That should be minimised. Unless you're proposing that vectors would sometimes be implemented without FP16, which I doubt.

The use-cases I can think of for FP16 (machine learning, graphics) would all seem to be inherently vector/SIMD/SIMT oriented.

On Wed, Apr 26, 2017 at 12:12 PM, Po-wei Huang <poweih...@gmail.com> wrote:

Hi Krste,
Why don’t we decouple FP16 from vector, as it should be a stand alone extension.
Best,
Po-wei

> kr...@berkeley.edu 於 2017年4月26日 下午5:11 寫道：
>
>
> FP16 is added as part of the V vector spec.
>
>
> Krste
>
>>>>>> On Wed, 26 Apr 2017 17:10:20 +0800, joxie xie <tshm...@gmail.com> said:
>
> | Hello RISC-V community,
> | We are evaluating if a RISC-V processor can be used in deep learning use cases,
> | for deep learning a FP16 is already good enough. AFAIK ARM provides
> | instructions to convert between FP16 and FP32 in VFPV3, I was wondering why
> | RISC-V does not have something similar, an extension with FP16 instructions
> | would be even better for small implementations using compressed ISA.
>
> | Any thoughts?
>
> | -Thanks
>
> | --
> | 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+unsubscribe@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/
> | CAGBX-%3DBHa3VmNKbqK6W8dB7kwCHvXEHY65k3XfGYrLSc5P3n3A%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+unsubscribe@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/22784.25640.545433.712308%40KAMacBookPro2016.local.

--
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+unsubscribe@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/583E0F37-00B1-4050-86FB-D5EAAA223A04%40gmail.com.

[Po-wei Huang]

Hi Bruce,

The reason I talked about “should” comes from orthogonality.

The reasons that you and Krste provided are certainly valid. However,if we follow the same philosophy and live in a 64-bit centric world,  we should have put FP32 into vector spec.

The current scheme:

FP16 FP32 FP64

Bundled with Vector Stand-alone Stand-alone

Why don’t we do like this:

FP16  FP32  FP64

Bundled with Vector Bundled with Vector Stand-alone

or this:

FP16  FP32  FP64

Stand-aline Stand-alone Stand-alone

Is the current scheme a design choice for contemporary use-case? 

Best,

Po-wei 

[joxie xie]

Agreed..

However I can also imagine conversion instruction between fp16 and fp32 useful though that seems to be a nice to have thing.

|| | to isa-dev+unsubscribe@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/
|| | CAGBX-%3DBHa3VmNKbqK6W8dB7kwCHvXEHY65k3XfGYrLSc5P3n3A%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+unsubscribe@groups.riscv.org.

[kr...@berkeley.edu]

The difference is there are many use cases for RV32, where the natural
width of a system is 32 bits and also many use cases where scalar
32-bit FP is useful (e.g, DSP).

If we had RV16, FP16 separated out might make sense.

And no, we're not going to do RV16.

Krste

>>>>> On Wed, 26 Apr 2017 17:41:14 +0800, Po-wei Huang <poweih...@gmail.com> said:

| Hi Bruce,
| The reason I talked about should comes from orthogonality.
| The reasons that you and Krste provided are certainly valid. However,if we
| follow the same philosophy and live in a 64-bit centric world, we should have
| put FP32 into vector spec.

| The current scheme:
| FP16 FP32 FP64
| Bundled with Vector Stand-alone Stand-alone

| Why don t we do like this:
| FP16 FP32 FP64
| Bundled with Vector Bundled with Vector Stand-alone

| or this:
| FP16 FP32 FP64
| Stand-aline Stand-alone Stand-alone

| Is the current scheme a design choice for contemporary use-case?
| Best,
| Po-wei

| Bruce Hoult <br...@hoult.org> 2017�¹ 4 26 �¸ 5:24 寫é �¼

| Hi Po-wei, "should", why?

| On the plus side there is obviously an argument from orthogonality.

| On the minus side there is the danger of an explosion of the number of
| combinations of extensions. That should be minimised. Unless you're
| proposing that vectors would sometimes be implemented without FP16, which I
| doubt.

| The use-cases I can think of for FP16 (machine learning, graphics) would
| all seem to be inherently vector/SIMD/SIMT oriented.

| On Wed, Apr 26, 2017 at 12:12 PM, Po-wei Huang <poweih...@gmail.com>
| wrote:

| Hi Krste,
| Why don t we decouple FP16 from vector, as it should be a stand alone
| extension.
| Best,
| Po-wei

|| kr...@berkeley.edu 2017�¹ 4 26 �¸ 5:11 寫é �¼

||
||
|| FP16 is added as part of the V vector spec.
||
||
|| Krste
||
||||||| On Wed, 26 Apr 2017 17:10:20 +0800, joxie xie <
| tshm...@gmail.com> said:
||
|| | Hello RISC-V community,
|| | We are evaluating if a RISC-V processor can be used in deep
| learning use cases,
|| | for deep learning a FP16 is already good enough. AFAIK ARM provides
|| | instructions to convert between FP16 and FP32 in VFPV3, I was
| wondering why
|| | RISC-V does not have something similar, an extension with FP16
| instructions
|| | would be even better for small implementations using compressed
| ISA.
||
|| | Any thoughts?
||
|| | -Thanks
||
|| | --
|| | 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/
|| | CAGBX-%3DBHa3VmNKbqK6W8dB7kwCHvXEHY65k3XfGYrLSc5P3n3A%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 https://groups.google.com/a/

| groups.riscv.org/d/msgid/isa-dev/22784.25640.545433.712308%
| 40KAMacBookPro2016.local.

| --
| 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/583E0F37-00B1-4050-86FB-
| D5EAAA223A04%40gmail.com.

[Bruce Hoult]

I personally would not object to load/store half precision FP (or even quarter precision FP) being supported, but stored in the CPU as single FP, and no instructions to do calculations on half FP. There are natural places for those in the LOAD-FP (0000111) and STORE-FP (0100111) major opcodes, parallel to the LOAD-INT and STORE-INT opcodes. Single and double already use the same 010 and 011 size encodings as integer word and doubleword, while 001 and 000 (short and byte) encodings are currently unused (let alone the "unsigned" bit). [User-Level ISA spec 2.1 doesn't make it clear what encodings are intended for Quad precision FP load/store. :-( ]

|| | 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/
|| | CAGBX-%3DBHa3VmNKbqK6W8dB7kwCHvXEHY65k3XfGYrLSc5P3n3A%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 https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/22784.25640.545433.712308%40KAMacBookPro2016.local.

--
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+unsubscribe@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/CAGBX-%3DD3Yk7xLXF%3D41sS4j1txD-4eBFBCsZXS1ifpNapnmq_6A%40mail.gmail.com.

[kr...@berkeley.edu]

>>>>> On Wed, 26 Apr 2017 16:07:37 +0300, Bruce Hoult <br...@hoult.org> said:

| I personally would not object to load/store half precision FP (or even quarter
| precision FP) being supported, but stored in the CPU as single FP, and no
| instructions to do calculations on half FP. There are natural places for those
| in the LOAD-FP (0000111) and STORE-FP (0100111) major opcodes, parallel to the
| LOAD-INT and STORE-INT opcodes. Single and double already use the same 010 and
| 011 size encodings as integer word and doubleword, while 001 and 000 (short and
| byte) encodings are currently unused (let alone the "unsigned" bit).
| [User-Level ISA spec 2.1 doesn't make it clear what encodings are intended for
| Quad precision FP load/store. :-( ]

Not in the best place admittedly, but Table 19.1 in the tentative P
chapter gives the width encoding.

Krste

| || | To view this discussion on the web visit https://groups.google.com
| /a/
| || | groups.riscv.org/d/msgid/isa-dev/
| || | CAGBX-%3DBHa3VmNKbqK6W8dB7kwCHvXEHY65k3XfGYrLSc5P3n3A%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 https://groups.google.com/a

| /groups.riscv.org/d/msgid/isa-dev/22784.25640.545433.712308%40K
| AMacBookPro2016.local.

| --
| 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/CAGBX-%3DD3Yk7xLXF%3D41sS4j1txD-
| 4eBFBCsZXS1ifpNapnmq_6A%40mail.gmail.com.

[Mark Friedenbach]

That's a fine rationale. However there may be a reasonable
justification for supporting hardware conversion to/from FP16 without
actually supporting FP16 operations.This would be useful for
interacting with or controlling hardware that uses FP16 formatted
data. Texture setup in a GPU shared memory space, for example.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/22784.26243.281206.876769%40KAMacBookPro2016.local.

[kr...@berkeley.edu]

Rather than define separate load/stores that convert
in/out of FP16, we'd recommend fusing:

FLH f1, ...; FCVT.S.H f1, f1
and
FCVT.H.S f0, f1; FSH f0, ... # Can reuse f1 if dead after store.

if your application needs this.

I don't think we'd want to specify a subextension or profile for only
this subset.

Krste

[Jacob Bachmeyer]

kr...@berkeley.edu wrote:
> On Wed, 26 Apr 2017 16:07:37 +0300, Bruce Hoult <br...@hoult.org> said:
> | I personally would not object to load/store half precision FP (or even quarter
> | precision FP) being supported, but stored in the CPU as single FP, and no
> | instructions to do calculations on half FP. There are natural places for those
> | in the LOAD-FP (0000111) and STORE-FP (0100111) major opcodes, parallel to the
> | LOAD-INT and STORE-INT opcodes. Single and double already use the same 010 and
> | 011 size encodings as integer word and doubleword, while 001 and 000 (short and
> | byte) encodings are currently unused (let alone the "unsigned" bit).
> | [User-Level ISA spec 2.1 doesn't make it clear what encodings are intended for
> | Quad precision FP load/store. :-( ]
>
> Not in the best place admittedly, but Table 19.1 in the tentative P
> chapter gives the width encoding.
>

That use of a wider FLEN (in P) may have unintended interactions with
the specification of NaN-boxed floats in section 8.2. Do we really want
to require implementations supporting P's Q8 mode to expand all floats
to 1024 bits?

Perhaps defining a separate PFLEN>=FLEN for P might be a simpler way to
specify this?


-- Jacob

[Krste Asanovic]

The wider P was intended only for packed SIMD use, with smaller elements.

Good point that FLEN doesn’t mean quite the same there.

After last workshop, sentiment was to drop P in favor of V, and to focus on packed-SIMD on integer registers for systems without FPUs at all.

Krste

[Rogier Brussee]

Op woensdag 26 april 2017 19:23:32 UTC+2 schreef krste:

Rather than define separate load/stores that convert
in/out of FP16, we'd recommend fusing:

     FLH f1, ...; FCVT.S.H f1, f1
and
     FCVT.H.S f0, f1; FSH f0, ...  # Can reuse f1 if dead after store.

if your application needs this.

I don't think we'd want to specify a subextension or profile for only
this subset.

Krste

Halfs are increasingly used in image file formats and there are voices to make them part of the C++ standard (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0192r0.pdf). Technically, supporting half floats this way seems like a very reasonable thing to do that reuses HW and ISA for 32bit floats. But if I understand correctly FLH and FCVT.H.S. are part of the P and/or V extension. Hence it is unlikely to be supported by compilers and marketing wise, you are producing a "non standards conforming" processor. An alternative way to support half floats would be a LH  rd rs1 imm;  XHalf.FMV.X.S frd rd. although you cannot fuse that.  

By the way, it is not even totally unambiguous what FCVT.H.S means, as in the rest of the standard H usually means half word integer (aka bit pattern) as in FCVT.W.S.  

In any case it seems there is a real advantage to having a canonical way to support halfs without having to implement the full P or V spec.

Rogier

[Stefan O'Rear]

On Fri, Apr 28, 2017 at 1:17 AM, Rogier Brussee
<rogier....@gmail.com> wrote:
> In any case it seems there is a real advantage to having a canonical way to
> support halfs without having to implement the full P or V spec.

These are early days for the V extension; we have a good idea of the
structure but much less of the specific menu of vectorized operations
(eg see the segmented-scan proposal from a few months back; and there
are a lot of plausible DSP and graphics applications that would
naturally piggyback on a vector register file…).

So far we've avoided a la carte-ing the user extensions to avoid a
proliferation of build modes. Right now V is not standard so any
subset of V is also not standard; I don't think it makes sense to
spend a lot of time discussing standard ways to subset nonstandard
extensions.

-s

[Rogier Brussee]

Op donderdag 4 mei 2017 11:26:04 UTC+2 schreef Stefan O'Rear:

I can see the avoid proliferation of extensions argument. 

Just that Krste suggested an entirely reasonable half float H extension that seems implementable with quite minimal extra hw provided F is implemented with just 4 instructions:

FLH frd imm12(rs1)

FSH frs1 imm12(rs2)

FCVT.H.W frd frs1

FCVT.W.H frd frs1

but it has the unfortunate non technical flaw that its "officially" part of a yet  unfinished standard which is obviously rather massive.

Rogier

-s

[lkcl]

On Thursday, May 4, 2017 at 10:26:04 AM UTC+1, Stefan O'Rear wrote:

So far we've avoided a la carte-ing the user extensions to avoid a
proliferation of build modes.  Right now V is not standard so any
subset of V is also not standard; I don't think it makes sense to
spend a lot of time discussing standard ways to subset nonstandard
extensions.

 apologies but you probably meant draft extensions, there, not nonstandard extensions.

 i don't see how that follows, stefan.  that nobody's publicly implemented the V extensions should tell you that it's too much.  if it _was_ permitted to implement subsets then people would _implement_ subsets... and consequently it would be possible for people to contribute meaningfully to the discussion because they would have the necessary information and learning experiences.

 right now there's only one implementation known about - hwacha - which realistically makes for a single group totally in charge / control of V and they *haven't published the work for anyone else to study, improve on, or replicate their findings*.

 everybody else, because of the sheer volume of work involved, is holding off, and *certainly* doesn't want to commit resources to implementing something that might get changed or thrown out.

 a subset of the V spec would allow people to contribute, discuss and learn *incrementally*.

 a proposed SIMD extension would allow people *again* to do incremental development because it would be much easier to add to an existing design.  replicate a few pre-existing ALU blocks and you're pretty much done.  by comparison the V extension is *really* comprehensive, it's one of the good [and bad] bits about it.  i love the polymorphism so that you can add ints to floats without needing to specify the types in the instruction.  it's extremely efficient... and a heck of a lot of work at the same time.

l.

[Sober Liu]

Hi,
Repick up this thread, also checked thread “FP16 FCVT needed (int, uint, fp32, fp64)”.

I am trying to create a simple demo test cases for fp16-add with vector instruction (e.g., vfadd.*).
The 1st task for me is to prepare fp16 data in continued 16-bits memory area, and load them to vector registers with vector load instructions.
After vector operations, I need to save results from vregs to memory, and check each result from memory.

Just wondering, if type __fp16 is not supported standalone in C program, how can I make that?
Currently, I see a proposal like below:
➢ FLH frd imm12(rs1)

➢ FSH frs1 imm12(rs2)
➢ FCVT.H.W frd frs1
➢ FCVT.W.H frd frs1

If only standalone fp32 (float type) is supported in C program, this means explicit inline asm instructions "FCVT.H.W frd frs1 + FSH frs1 imm12(rs2)" to write memory, and "FLH frd imm12(rs1) + FCVT.W.H frd frs1" to read memory.
For each data element, there are 2 extra FCVT instructions involved. Not sure for the benefit from vector operations, v.s. using fp32 instructions directly.

Regards.

--
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 mailto:isa-dev+u...@groups.riscv.org.
To post to this group, send email to mailto: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/8abf1c2a-5f41-409e-a6be-0765079cff9f%40groups.riscv.org?utm_medium=email&utm_source=footer.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------