Must start with an even-numbered register.

Add operand constraint for inline asm statement.

Add miminal common operand constraint between LLVM and GCC.

Plan to extend this like vector register constraint in future.

Let's establish a naming guideline for intrinsics.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

Add misc macro for vector extensions.

Introduce `__riscv_min_vlen`, `__riscv_v_elen` and `__riscv_v_elen_fp`
macro, for let programer easier to get vector related information, like:

- What's the minimal VLEN value is guaranteed current architecture
  extension?
- What's the maximal available ELEN is guaranteed current
  architecture extension?
- What's the maximal available ELEN for floating-point operation is
  guaranteed current architecture extension?

It's possible to get the information by testing serveral architecture extension
test macro, but the life can be simpler if toolchain can help, for
example, if you want to check the minimal VLEN value via those macro:

```c
 #if defined(__riscv_zvl512b)
   #define __riscv_min_vlen 512
 #elif defined(__riscv_zvl256b)
   #define __riscv_min_vlen 256
 #elif defined(__riscv_zvl128b) || defined(__riscv_v)
   #define __riscv_min_vlen 128
 #elif defined(__riscv_zvl64b) || defined(__riscv_zve64x) || \
       defined(__riscv_zve64f) || defined(__riscv_zve64d)
   #define __riscv_min_vlen 64
 #elif defined(__riscv_zvl32b) || defined(__riscv_zve32x) || \
       defined(__riscv_zve32f)
   #define __riscv_min_vlen 32
 #endif

```

And it's not scalable solution since in theory we can have up to zvl32768b.

Add __riscv_vector back from deprecated

After adding the zve extension it is not obvious for user whether if there is
any vector instructions available. Adding __riscv_vector will let the users
able to check this.

Add pre-defined macro __riscv_p for P extension

Use Zb[abcs] instead of B/Bitmanip

We don't have a single B/Bitmanip extension, but several extensions
Zb[abcs], which can be available independent of each other.
Let's fix that in this document.
Given that there was never a ratified Bitmanip extensions,
I don't think that this change causes any real-world problems.

Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>

Correct example definition of __riscv_f

Fixed Code Tags

Introduce new scheme of extension related predefined macro

The motivation of this scheme is have an unify naming scheme for
extension macro and add the capability to checking version.

The new naming scheme is `__riscv_<extension name>`, and it will define
the value to `<MAJOR_VERSION> * 1,000,000 + <MINOR_VERSION> * 1,000 + <REVISION_VERSION>`

For example:
 - F-extension v2.2 will define `__riscv_f` as `2002000`.
 - B-extension v0.92 will define `__riscv_b` as `92000`.

We also introduce a new macro `__riscv_arch_test_marco` to check this
test marco set is available.

Reorg `Preprocessor Definitions` section.

Co-authored-by: Jim Wilson <jimw@sifive.com>

Co-authored-by: Sam Elliott <sam@lenary.co.uk>

Mention __riscv_div, __riscv_muldiv, __riscv_fdiv and __riscv_fsqrt won't defined when -mno-div and -mno-fdiv option is given

 - Tabularization, add category for those macro definitions and describe
   when will define.

Add __riscv_fp16 for Zfh extension

Add __riscv_vector and __riscv_bitmanip for V and B extensions.

Add new __riscv_abi_rve macro.

Change "preprosser" to "preprocessor"
Closes #5

Add missing options, preprocessor macros, and attributes.

Signed-off-by: Palmer Dabbelt <palmer@sifive.com>