From 7188f578046543e2206d0ed190faee7750739504 Mon Sep 17 00:00:00 2001 From: Bill Traynor Date: Sun, 18 Dec 2022 00:02:45 -0500 Subject: Fixed quotes that converted incorrectly and table refs. Fixed quotes that did not convert correctly. Added new displayed text for table refs. --- src/extending.adoc | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'src/extending.adoc') diff --git a/src/extending.adoc b/src/extending.adoc index a7c319d..965f1f3 100644 --- a/src/extending.adoc +++ b/src/extending.adoc @@ -31,7 +31,7 @@ categories: _standard_ versus _non-standard_. * A standard extension is one that is generally useful and that is designed to not conflict with any other standard extension. Currently, -`MAFDQLCBTPV`, described in other chapters of this manual, are either +"MAFDQLCBTPV", described in other chapters of this manual, are either complete or planned standard extensions. * A non-standard extension may be highly specialized and may conflict with other standard or non-standard extensions. We anticipate a wide @@ -44,17 +44,17 @@ An instruction encoding space is some number of instruction bits within which a base ISA or ISA extension is encoded. RISC-V supports varying instruction lengths, but even within a single instruction length, there are various sizes of encoding space available. For example, the base -ISAs are defined within a 30-bit encoding space (bits 31–2 of the 32-bit -instruction), while the atomic extension ``A`` fits within a 25-bit -encoding space (bits 31–7). +ISAs are defined within a 30-bit encoding space (bits 31-2 of the 32-bit +instruction), while the atomic extension "A" fits within a 25-bit +encoding space (bits 31-7). We use the term _prefix_ to refer to the bits to the _right_ of an instruction encoding space (since instruction fetch in RISC-V is little-endian, the bits to the right are stored at earlier memory addresses, hence form a prefix in instruction-fetch order). The prefix -for the standard base ISA encoding is the two-bit `11` field held in -bits 1–0 of the 32-bit word, while the prefix for the standard atomic -extension `A` is the seven-bit `0101111` field held in bits 6–0 of +for the standard base ISA encoding is the two-bit "11" field held in +bits 1-0 of the 32-bit word, while the prefix for the standard atomic +extension "A" is the seven-bit "0101111" field held in bits 6-0 of the 32-bit word representing the AMO major opcode. A quirk of the encoding format is that the 3-bit funct3 field used to encode a minor opcode is not contiguous with the major opcode bits in the 32-bit @@ -64,7 +64,7 @@ instruction spaces. Although an instruction encoding space could be of any size, adopting a smaller set of common sizes simplifies packing independently developed extensions into a single global encoding. -<> gives the suggested sizes for RISC-V. +<> gives the suggested sizes for RISC-V. [[encodingspaces]] .Suggested standard RISC-V instruction encoding space sizes. @@ -136,7 +136,7 @@ itself. |Brownfield |F(I), D(F), Q(D) |M(I) |=== -<> shows the bases and standard extensions placed +<> shows the bases and standard extensions placed in a simple two-dimensional taxonomy. One axis is whether the extension is greenfield or brownfield, while the other axis is whether the extension adds architectural state. For greenfield extensions, the size @@ -243,7 +243,7 @@ A 25-bit instruction encoding space corresponds to a major opcode in the base and standard extension encodings. There are four major opcodes expressly designated for custom extensions -<>, each of which represents a 25-bit +<>, each of which represents a 25-bit encoding space. Two of these are reserved for eventual use in the RV128 base encoding (will be OP-IMM-64 and OP-64), but can be used for non-standard extensions for RV32 and RV64. @@ -259,7 +259,7 @@ if the standard atomic extensions are not required. If an implementation does not require instructions longer than 32-bits, then an additional four major opcodes are available (those marked in -gray in <>. +gray in <>. The base RV32I encoding uses only 11 major opcodes plus 3 reserved opcodes, leaving up to 18 available for extensions. The base RV64I @@ -293,7 +293,7 @@ are aligned on 64-bit boundaries to simplify instruction fetch, with a 32-bit NOP instruction used as alignment padding where necessary. To simplify use of standard tools, the 64-bit instructions should be -encoded as described in <>. +encoded as described in <>. However, an implementation might choose a non-standard instruction-length encoding for 64-bit instructions, while retaining the standard encoding for 32-bit instructions. For example, if compressed @@ -324,7 +324,7 @@ VLIW code size expansion to VLIW-accelerated functions. ==== Encoded-Length Groups Another approach is to use the standard length encoding from -<> to encode parallel +<> to encode parallel instruction groups, allowing NOPs to be compressed out of the VLIW instruction. For example, a 64-bit instruction could hold two 28-bit operations, while a 96-bit instruction could hold three 28-bit @@ -354,7 +354,7 @@ to be supported. None of the above approaches retains the RISC-V encoding for the individual operations within a VLIW instruction. Yet another approach is to repurpose the two prefix bits in the fixed-width 32-bit encoding. One -prefix bit can be used to signal `end-of-group` if set, while the +prefix bit can be used to signal "end-of-group" if set, while the second bit could indicate execution under a predicate if clear. Standard RISC-V 32-bit instructions generated by tools unaware of the VLIW extension would have both prefix bits set (11) and thus have the correct -- cgit v1.1