Comments (11)
Hi @rjiejie :
My understanding is linux kernel won't accept an extension if it's not frozen or ratified [1], and GNU toolchain also following same rule too, so I think we might just keep upgrading until vector extension frozen or ratified.
[1] https://lkml.org/lkml/2019/11/22/2169
from rvv-intrinsic-doc.
Oh, seems like I misunderstanding, you are metaphor that's like long term version of Linux kernel, not talking about linux kernel itself.
But upstream won't support those version, so personally I think it's not so useful to maintain multiple version of intrinsic spec.
from rvv-intrinsic-doc.
There may be some test/validation/demo hardware using intermediate versions of V, but there won't be a 'production' version with a non-ratified version of the specification, at least not from the EPI side.
You need well-defined, agreed-upon specifications & a thriving software ecosystem to be able to define something as 'production-ready', and start exploiting high-performance silicon. To give you an idea, Intel made the final specifications, compiler & emulator available for nearly two years before AVX-512 was available in silicon with Knight Landings. Similar for SVE, specifications & toolchain from Arm were around for at least two years before A64FX started running code. That's what you need to make sure a) the toolchain works b) the software will be there when the hardware is available c) the hardware actually behave as advertised on a large variety of codes.
from rvv-intrinsic-doc.
Hi @rjiejie,
Indeed, when we discussed the RFC, we only considered v0.8 and later. The RFC lists naming rules and exceptional cases for the function lists. I do not dig into v0.7.1. Could you help us to point out the incompatible parts between v0.7.1 and these guidelines in the RFC? Maybe you could help us to create a version for v0.7.1 and generate the function lists for v0.7.1. We could create a branch for it.
from rvv-intrinsic-doc.
@Hsiangkai @rjiejie It might be nice to have some level of compatibility with old drafts, but is it really useful in practice? Everything is going to move to whatever turns out to be ratified. Whomever is going forward with v0.7.1 hardware is going to do it for testing purpose only presumably, and will only need enough software to validate the silicon - not for long-term support.
So I tend to agree with @kito-cheng that it's probably not worth the effort.
from rvv-intrinsic-doc.
I agree. We will not maintain the documents for v0.7.1. If @rjiejie thinks it is necessary to have it, they need to maintain it by themselves. I could help them to create a branch for v0.7.1. here.
from rvv-intrinsic-doc.
Hi @rjiejie,
Indeed, when we discussed the RFC, we only considered v0.8 and later. The RFC lists naming rules and exceptional cases for the function lists. I do not dig into v0.7.1. Could you help us to point out the incompatible parts between v0.7.1 and these guidelines in the RFC? Maybe you could help us to create a version for v0.7.1 and generate the function lists for v0.7.1. We could create a branch for it.
Thank you, I will dig difference detailed with a short time :)
from rvv-intrinsic-doc.
I agree. We will not maintain the documents for v0.7.1. If @rjiejie thinks it is necessary to have it, they need to maintain it by themselves. I could help them to create a branch for v0.7.1. here.
Hi @Hsiangkai ,
Thanks again.
A little of instructions are deleted from the first stable spec v0.7.1 to the latest,
we should add the the following interface to the RFC to cover all vector specs :)
And for future of vector spec forwarding, we should consider all release vector specs.
We could use some compiler supported macro to identify the specific interfaces.
Also we could do this part work with you to maintain all vector spec interface in the RFC
if there are much work to do with it.
The following are absent interfaces from the first stable spec.
Integer Extract Instruction:
vext.x.v
Vector Single-Width Averaging Add and Subtract:
vaadd.vi
Vector Widening Saturating Scaled Multiply-Add:
vwsmaccu.vv
vwsmaccu.vx
vwsmacc.vv
vwsmacc.vx
vwsmaccsu.vv
vwsmaccsu.vx
vwsmaccus.vx
Vector Floating-Point Compare Instructions:
vmford.vv
vmford.vf
from rvv-intrinsic-doc.
I agree. We will not maintain the documents for v0.7.1. If @rjiejie thinks it is necessary to have it, they need to maintain it by themselves. I could help them to create a branch for v0.7.1. here.
Hi @Hsiangkai ,
Thanks again. A little of instructions are deleted from the first stable spec v0.7.1 to the latest, we should add the the following interface to the RFC to cover all vector specs :) And for future of vector spec forwarding, we should consider all release vector specs. We could use some compiler supported macro to identify the specific interfaces. Also we could do this part work with you to maintain all vector spec interface in the RFC if there are much work to do with it.
The following are absent interfaces from the first stable spec.
Integer Extract Instruction:
vext.x.v
Vector Single-Width Averaging Add and Subtract:
vaadd.vi
Vector Widening Saturating Scaled Multiply-Add:
vwsmaccu.vv vwsmaccu.vx vwsmacc.vv vwsmacc.vx vwsmaccsu.vv vwsmaccsu.vx vwsmaccus.vx
Vector Floating-Point Compare Instructions:
vmford.vv vmford.vf
I have created a branch, v0.7.1, for you. Could you help us to update the documents to align to v0.7.1 in that branch?
from rvv-intrinsic-doc.
The current RVV intrinsic follows the latest ratified v-spec v1.0 and the implementation for v0.7 is not in the considered as part of the standard. Maybe we can close this since the current status works for the majority?
Any thoughts on this?
from rvv-intrinsic-doc.
The intrinsics implement the ratified RISC-V "V" extension.
from rvv-intrinsic-doc.
Related Issues (20)
- Type-relative overloads for vreinterpret, vlmul_ext, vlmul_trunc, etc. HOT 1
- How to use a class to wrap or derive from a sizeless vector type HOT 1
- Encode all the effects of vsetvl in the return type, for use in subsequent type deductions HOT 1
- Does `__riscv_v_intrinsic >= 1000000` imply overloaded intrinsics are supported?
- Create bibliography from reference section HOT 3
- Simple questions about inline assembly in vmv.x.s instruction HOT 2
- Asterisks are not subscripts
- the wrong result of "vmerge_vvm_i32m1" HOT 5
- ta,ma reduction destination with vl=0 HOT 1
- Clarify the consequences of vxsat not being handled by the intrinsics HOT 3
- Add a section with examples HOT 3
- Rename uses of {implicit,explicit}-frm into {Implicit, Explicit} FP rounding mode HOT 1
- Clarify the mapping of pseudo-intrinsics
- Clarify what float and double means HOT 1
- Fix authors in the document
- How to use LMUL in rvv-intrinsic? HOT 6
- Mismatched bfloat16 autogenerated files HOT 3
- Freeze the specification HOT 1
- `vfirst` and `vcpop` return types unexpectedly changed HOT 1
- Renaming the VL arguments to AVL HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rvv-intrinsic-doc.